[Intel-gfx] [PATCH v2] Revert "drm/i915/chv: Set min freq to efficient frequency on chv"

[deepak . s]

From: Deepak S 

With latest Punit FW, vgg input voltag drop falling to minimum is fixed.
So reverting the WA patch & moving to turbo freq opreation range to [RPn -> RP0]

This reverts commit 5b7c91b78b1ce6663e0f1f037f6cb4d7c9537d44.

commit 5b7c91b78b1ce6663e0f1f037f6cb4d7c9537d44
Author: Deepak S 
Date:   Sat May 9 18:15:46 2015 +0530

drm/i915/chv: Set min freq to efficient frequency on chv

v2: Fix inconsistent return type. (Chris)

Acked-by: Chris Wilson 
Signed-off-by: Deepak S 
---
 drivers/gpu/drm/i915/intel_pm.c | 21 +++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 81ab119..7844bf5 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5579,6 +5579,24 @@ static int cherryview_rps_guar_freq(struct 
drm_i915_private *dev_priv)
return rp1;
 }
 
+static u32 cherryview_rps_min_freq(struct drm_i915_private *dev_priv)
+{
+   struct pci_device *pdev = dev_priv->drm.pdev;
+   u32 val, rpn;
+
+   if (pdev->revision >= 0x20) {
+   val = vlv_punit_read(dev_priv, FB_GFX_FMIN_AT_VMIN_FUSE);
+   rpn = ((val >> FB_GFX_FMIN_AT_VMIN_FUSE_SHIFT) &
+  FB_GFX_FREQ_FUSE_MASK);
+   } else { /* For pre-production hardware */
+   val = vlv_punit_read(dev_priv, PUNIT_GPU_STATUS_REG);
+   rpn = ((val >> PUNIT_GPU_STATIS_GFX_MIN_FREQ_SHIFT) &
+  PUNIT_GPU_STATUS_GFX_MIN_FREQ_MASK);
+   }
+
+   return rpn;
+}
+
 static int valleyview_rps_guar_freq(struct drm_i915_private *dev_priv)
 {
u32 val, rp1;
@@ -5818,8 +5836,7 @@ static void cherryview_init_gt_powersave(struct 
drm_i915_private *dev_priv)
 intel_gpu_freq(dev_priv, dev_priv->rps.rp1_freq),
 dev_priv->rps.rp1_freq);
 
-   /* PUnit validated range is only [RPe, RP0] */
-   dev_priv->rps.min_freq = dev_priv->rps.efficient_freq;
+   dev_priv->rps.min_freq = cherryview_rps_min_freq(dev_priv);
DRM_DEBUG_DRIVER("min GPU freq: %d MHz (%u)\n",
 intel_gpu_freq(dev_priv, dev_priv->rps.min_freq),
 dev_priv->rps.min_freq);
-- 
1.9.1

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

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: intel_dp_link_is_valid() should only return status of link (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: intel_dp_link_is_valid() should only return status of link 
(rev2)
URL   : https://patchwork.freedesktop.org/series/9737/
State : failure

== Summary ==

Series 9737v2 drm/i915: intel_dp_link_is_valid() should only return status of 
link
http://patchwork.freedesktop.org/api/1.0/series/9737/revisions/2/mbox

Test gem_exec_suspend:
Subgroup basic-s3:
pass   -> INCOMPLETE (fi-hsw-i7-4770k)
Test gem_flink_basic:
Subgroup bad-open:
pass   -> INCOMPLETE (fi-skl-i7-6700k)
Test kms_cursor_legacy:
Subgroup basic-cursor-vs-flip-varying-size:
pass   -> FAIL   (ro-ilk1-i5-650)
Subgroup basic-flip-vs-cursor-legacy:
fail   -> PASS   (ro-skl3-i5-6260u)
Subgroup basic-flip-vs-cursor-varying-size:
fail   -> PASS   (ro-byt-n2820)
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-a:
pass   -> DMESG-WARN (ro-byt-n2820)
Subgroup read-crc-pipe-b-frame-sequence:
fail   -> PASS   (ro-ivb2-i7-3770)
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> SKIP   (ro-bdw-i5-5250u)
Subgroup suspend-read-crc-pipe-c:
skip   -> DMESG-WARN (ro-bdw-i5-5250u)

fi-hsw-i7-4770k  total:107  pass:91   dwarn:0   dfail:0   fail:0   skip:15 
fi-kbl-qkkr  total:244  pass:186  dwarn:28  dfail:0   fail:3   skip:27 
fi-skl-i5-6260u  total:244  pass:224  dwarn:4   dfail:0   fail:2   skip:14 
fi-skl-i7-6700k  total:112  pass:87   dwarn:1   dfail:0   fail:0   skip:23 
fi-snb-i7-2600   total:244  pass:202  dwarn:0   dfail:0   fail:0   skip:42 
ro-bdw-i5-5250u  total:240  pass:218  dwarn:2   dfail:0   fail:2   skip:18 
ro-bdw-i7-5600u  total:240  pass:206  dwarn:1   dfail:0   fail:1   skip:32 
ro-bsw-n3050 total:240  pass:193  dwarn:0   dfail:0   fail:4   skip:43 
ro-byt-n2820 total:240  pass:197  dwarn:1   dfail:0   fail:2   skip:40 
ro-hsw-i3-4010u  total:240  pass:214  dwarn:0   dfail:0   fail:0   skip:26 
ro-hsw-i7-4770r  total:240  pass:185  dwarn:0   dfail:0   fail:0   skip:55 
ro-ilk1-i5-650   total:235  pass:173  dwarn:0   dfail:0   fail:2   skip:60 
ro-ivb-i7-3770   total:240  pass:205  dwarn:0   dfail:0   fail:0   skip:35 
ro-ivb2-i7-3770  total:240  pass:209  dwarn:0   dfail:0   fail:0   skip:31 
ro-skl3-i5-6260u total:240  pass:223  dwarn:0   dfail:0   fail:3   skip:14 

Results at /archive/results/CI_IGT_test/RO_Patchwork_1843/

4a26251 drm-intel-nightly: 2016y-08m-11d-16h-12m-42s UTC integration manifest
3d6ab56 drm/i915: intel_dp_link_is_valid() should only return status of link

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

Re: [Intel-gfx] [PATCH] Revert "drm/i915/chv: Set min freq to efficient frequency on chv"

[Chris Wilson]

On Fri, Aug 12, 2016 at 02:20:34PM +0530, deepa...@linux.intel.com wrote:
> From: Deepak S 
> 
> With latest Punit FW, vgg input voltag drop falling to minimum is fixed.
> So reverting the WA patch & moving to turbo freq opreation range to [RPn -> 
> RP0]
> 
> This reverts commit 5b7c91b78b1ce6663e0f1f037f6cb4d7c9537d44.
> 
> commit 5b7c91b78b1ce6663e0f1f037f6cb4d7c9537d44
> Author: Deepak S 
> Date:   Sat May 9 18:15:46 2015 +0530
> 
> drm/i915/chv: Set min freq to efficient frequency on chv
> 
> Signed-off-by: Deepak S 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 21 +++--
>  1 file changed, 19 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 81ab119..e59799a 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -5579,6 +5579,24 @@ static int cherryview_rps_guar_freq(struct 
> drm_i915_private *dev_priv)
>   return rp1;
>  }
>  
> +static int cherryview_rps_min_freq(struct drm_i915_private *dev_priv)

Return int, but compute a u32? Just inconsistent.

> +{
> + struct drm_device *dev = _priv->drm;

struct pci_device *pdev = dev_priv->drm.pdev;

> + u32 val, rpn;
> +
> + if (dev->pdev->revision >= 0x20) {
> + val = vlv_punit_read(dev_priv, FB_GFX_FMIN_AT_VMIN_FUSE);
> + rpn = ((val >> FB_GFX_FMIN_AT_VMIN_FUSE_SHIFT) &
> +FB_GFX_FREQ_FUSE_MASK);
> + } else { /* For pre-production hardware */

} else { /* For pre-production hardware use RPe instead */

> + val = vlv_punit_read(dev_priv, PUNIT_GPU_STATUS_REG);
> + rpn = ((val >> PUNIT_GPU_STATIS_GFX_MIN_FREQ_SHIFT) &
> +PUNIT_GPU_STATUS_GFX_MIN_FREQ_MASK);
> + }

Acked-by: Chris Wilson 
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Ro.CI.BAT: failure for Finally fix watermarks (rev9)

[Patchwork]

== Series Details ==

Series: Finally fix watermarks (rev9)
URL   : https://patchwork.freedesktop.org/series/10276/
State : failure

== Summary ==

Series 10276v9 Finally fix watermarks
http://patchwork.freedesktop.org/api/1.0/series/10276/revisions/9/mbox

Test gem_exec_gttfill:
Subgroup basic:
pass   -> SKIP   (fi-snb-i7-2600)
Test gem_exec_suspend:
Subgroup basic-s3:
pass   -> DMESG-WARN (fi-hsw-i7-4770k)
dmesg-warn -> PASS   (ro-bdw-i7-5600u)
dmesg-warn -> PASS   (fi-skl-i5-6260u)
dmesg-warn -> PASS   (fi-skl-i7-6700k)
Test kms_cursor_legacy:
Subgroup basic-cursor-vs-flip-varying-size:
pass   -> FAIL   (ro-ilk1-i5-650)
Subgroup basic-flip-vs-cursor-legacy:
pass   -> FAIL   (fi-hsw-i7-4770k)
dmesg-fail -> FAIL   (fi-skl-i7-6700k)
Subgroup basic-flip-vs-cursor-varying-size:
dmesg-fail -> PASS   (fi-skl-i7-6700k)
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-b-frame-sequence:
fail   -> PASS   (ro-ivb2-i7-3770)
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-hsw-i7-4770k)
dmesg-warn -> SKIP   (ro-bdw-i5-5250u)
dmesg-warn -> PASS   (fi-skl-i5-6260u)
dmesg-warn -> PASS   (fi-skl-i7-6700k)
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-hsw-i7-4770k)
skip   -> DMESG-WARN (ro-bdw-i5-5250u)
dmesg-warn -> PASS   (fi-skl-i5-6260u)
dmesg-warn -> PASS   (fi-skl-i7-6700k)
Subgroup suspend-read-crc-pipe-c:
dmesg-warn -> PASS   (fi-skl-i5-6260u)
dmesg-warn -> PASS   (fi-skl-i7-6700k)

fi-hsw-i7-4770k  total:207  pass:183  dwarn:2   dfail:0   fail:1   skip:20 
fi-kbl-qkkr  total:244  pass:186  dwarn:29  dfail:0   fail:2   skip:27 
fi-skl-i5-6260u  total:244  pass:228  dwarn:0   dfail:0   fail:2   skip:14 
fi-skl-i7-6700k  total:244  pass:213  dwarn:0   dfail:0   fail:3   skip:28 
fi-snb-i7-2600   total:244  pass:201  dwarn:0   dfail:0   fail:0   skip:43 
ro-bdw-i5-5250u  total:240  pass:218  dwarn:2   dfail:0   fail:2   skip:18 
ro-bdw-i7-5600u  total:240  pass:207  dwarn:0   dfail:0   fail:1   skip:32 
ro-bsw-n3050 total:240  pass:194  dwarn:0   dfail:0   fail:4   skip:42 
ro-byt-n2820 total:240  pass:197  dwarn:0   dfail:0   fail:3   skip:40 
ro-hsw-i3-4010u  total:240  pass:214  dwarn:0   dfail:0   fail:0   skip:26 
ro-hsw-i7-4770r  total:240  pass:185  dwarn:0   dfail:0   fail:0   skip:55 
ro-ilk1-i5-650   total:235  pass:173  dwarn:0   dfail:0   fail:2   skip:60 
ro-ivb-i7-3770   total:240  pass:205  dwarn:0   dfail:0   fail:0   skip:35 
ro-ivb2-i7-3770  total:240  pass:209  dwarn:0   dfail:0   fail:0   skip:31 
ro-skl3-i5-6260u total:240  pass:222  dwarn:0   dfail:0   fail:4   skip:14 

Results at /archive/results/CI_IGT_test/RO_Patchwork_1842/

4a26251 drm-intel-nightly: 2016y-08m-11d-16h-12m-42s UTC integration manifest
03a294b drm/i915/skl: Update DDB values atomically with wms/plane attrs
f269f34 drm/i915: Move CRTC updating in atomic_commit into it's own hook
aa1c495 drm/i915/skl: Ensure pipes with changed wms get added to the state
486bb63 drm/i915/skl: Update plane watermarks atomically during plane updates
bdb3379 drm/i915/gen9: Only copy WM results for changed pipes to skl_hw
2acd342 drm/i915/skl: Add support for the SAGV, fix underrun hangs
a324893 drm/i915/gen6+: Return -EINVAL on invalid pcode commands

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

Re: [Intel-gfx] [PATCH v3] drm/i915/dp: DP audio API changes for MST

[Ville Syrjälä]

On Fri, Aug 12, 2016 at 04:28:09AM +, Pandiyan, Dhinakaran wrote:
> On Thu, 2016-08-11 at 10:39 +0300, Ville Syrjälä wrote:
> > On Thu, Aug 11, 2016 at 07:10:39AM +, Pandiyan, Dhinakaran wrote:
> > > On Thu, 2016-08-11 at 09:26 +0300, Ville Syrjälä wrote:
> > > > On Wed, Aug 10, 2016 at 12:41:57PM -0700, Dhinakaran Pandiyan wrote:
> > > > > DP MST provides the capability to send multiple video and audio 
> > > > > streams
> > > > > through a single port. This requires the API's between i915 and audio
> > > > > drivers to distinguish between multiple audio capable displays that 
> > > > > can be
> > > > > connected to a port. Currently only the port identity is shared in the
> > > > > APIs. This patch adds support for MST with an additional parameter
> > > > > 'int pipe'.  The existing parameter 'port' does not change it's 
> > > > > meaning.
> > > > > 
> > > > > pipe =
> > > > >   MST : display pipe that the stream originates from
> > > > >   Non-MST : -1
> > > > > 
> > > > > Affected APIs:
> > > > > struct i915_audio_component_ops
> > > > > -   int (*sync_audio_rate)(struct device *, int port, int rate);
> > > > > + int (*sync_audio_rate)(struct device *, int port, int pipe,
> > > > > +  int rate);
> > > > > 
> > > > > -   int (*get_eld)(struct device *, int port, bool *enabled,
> > > > > -   unsigned char *buf, int max_bytes);
> > > > > +   int (*get_eld)(struct device *, int port, int pipe,
> > > > > +bool *enabled, unsigned char *buf, int 
> > > > > max_bytes);
> > > > > 
> > > > > struct i915_audio_component_audio_ops
> > > > > -   void (*pin_eld_notify)(void *audio_ptr, int port);
> > > > > +   void (*pin_eld_notify)(void *audio_ptr, int port, int pipe);
> > > > > 
> > > > > This patch makes dummy changes in the audio drivers (Libin) for build 
> > > > > to
> > > > > succeed. The audio side drivers will send the right 'pipe' values in
> > > > > patches that will follow.
> > > > > 
> > > > > v2:
> > > > > Renamed the new API parameter from 'dev_id' to 'pipe'. (Jim, Ville)
> > > > > Included Asoc driver API compatibility changes from Jeeja.
> > > > > Added WARN_ON() for invalid pipe in get_saved_encoder(). (Takashi)
> > > > > Added comment for av_enc_map[] definition. (Takashi)
> > > > > 
> > > > > v3:
> > > > > Fixed logic error introduced while renaming 'dev_id' as 'pipe' (Ville)
> > > > > Renamed get_saved_encoder() to get_saved_enc() to reduce line length
> > > > > 
> > > > > Signed-off-by: Dhinakaran Pandiyan 
> > > > > ---
> > > > >  drivers/gpu/drm/i915/i915_drv.h|  3 +-
> > > > >  drivers/gpu/drm/i915/intel_audio.c | 93 
> > > > > ++
> > > > >  include/drm/i915_component.h   |  6 +--
> > > > >  include/sound/hda_i915.h   | 11 +++--
> > > > >  sound/hda/hdac_i915.c  |  9 ++--
> > > > >  sound/pci/hda/patch_hdmi.c |  7 +--
> > > > >  sound/soc/codecs/hdac_hdmi.c   |  2 +-
> > > > >  7 files changed, 86 insertions(+), 45 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > > index c36d176..8e4a88f 100644
> > > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > > @@ -2036,7 +2036,8 @@ struct drm_i915_private {
> > > > >   /* perform PHY state sanity checks? */
> > > > >   bool chv_phy_assert[2];
> > > > >  
> > > > > - struct intel_encoder *dig_port_map[I915_MAX_PORTS];
> > > > > + /* Used to save the pipe-to-encoder mapping for audio */
> > > > > + struct intel_encoder *av_enc_map[I915_MAX_PIPES];
> > > > >  
> > > > >   /*
> > > > >* NOTE: This is the dri1/ums dungeon, don't add stuff here. 
> > > > > Your patch
> > > > > diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> > > > > b/drivers/gpu/drm/i915/intel_audio.c
> > > > > index ef20875..a7467ea 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_audio.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > > > > @@ -500,6 +500,7 @@ void intel_audio_codec_enable(struct 
> > > > > intel_encoder *intel_encoder)
> > > > >   struct i915_audio_component *acomp = dev_priv->audio_component;
> > > > >   struct intel_digital_port *intel_dig_port = 
> > > > > enc_to_dig_port(encoder);
> > > > >   enum port port = intel_dig_port->port;
> > > > > + enum pipe pipe = crtc->pipe;
> > > > >  
> > > > >   connector = drm_select_eld(encoder);
> > > > >   if (!connector)
> > > > > @@ -524,12 +525,18 @@ void intel_audio_codec_enable(struct 
> > > > > intel_encoder *intel_encoder)
> > > > >  
> > > > >   mutex_lock(_priv->av_mutex);
> > > > >   intel_encoder->audio_connector = connector;
> > > > > +
> > > > >   /* referred in audio callbacks */
> > > > > - dev_priv->dig_port_map[port] = intel_encoder;
> > > > > + dev_priv->av_enc_map[pipe] = intel_encoder;
> > > > >  

Re: [Intel-gfx] [PATCH 1/3] drm/i915/psr:Adds Y-cordinate to skl_psr_setup_vsc

[vathsala nagaraju]

On Thursday 11 August 2016 01:30 PM, Ville Syrjälä wrote:

On Thu, Aug 11, 2016 at 01:07:50PM +0530, vathsala nagaraju wrote:

Adds Y-co-ordinate support to skl_psr_setup_vsc as
per edp 1.4 spec,table 6-11:VSC SDP HEADER
Extension for psr2 support.

Cc: Rodrigo Vivi 
Signed-off-by: vathsala nagaraju 
---
  drivers/gpu/drm/i915/i915_drv.h  |  2 ++
  drivers/gpu/drm/i915/intel_dp.c  | 22 ++
  drivers/gpu/drm/i915/intel_psr.c | 13 -
  include/drm/drm_dp_helper.h  |  5 -
  4 files changed, 40 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7f2754a..79ce64f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1022,6 +1022,8 @@ struct i915_psr {
bool psr2_support;
bool aux_frame_sync;
bool link_standby;
+   bool y_cord_support;
+   bool colorimetry_support;
  };
  
  enum intel_pch {

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 364db90..19e9ecf 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3439,6 +3439,28 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
dev_priv->psr.psr2_support = dev_priv->psr.aux_frame_sync;
DRM_DEBUG_KMS("PSR2 %s on sink",
  dev_priv->psr.psr2_support ? "supported" : "not 
supported");
+
+   if (dev_priv->psr.psr2_support) {
+   uint8_t psr_caps, dprx;
+
+   /*check if panel supports Y-Cordinate*/
+   drm_dp_dpcd_readb(_dp->aux,
+   DP_PSR_CAPS,
+   _caps);

intel_dp->edp_dpcd[1]

We should probably add something resembling dp_link_status() for each
DPCD chunk we cache, to make it less confusing to use them.


+   if (psr_caps & DP_PSR_Y_COORDINATE)
+   dev_priv->psr.y_cord_support = true;
+   else
+   dev_priv->psr.y_cord_support = false;
+   /* check for COLORIMETRY SUPPORT */
+   drm_dp_dpcd_readb(_dp->aux,
+   DPRX_FEATURE_ENUMERATION_LIST,
+   );
+   if (dprx & VSC_SDP_EXT_FOR_COLORIMETRY_SUPPORTED)
+   dev_priv->psr.colorimetry_support = true;
+   else
+   dev_priv->psr.colorimetry_support = false;
+   }
+
}
  
  	/* Read the eDP Display control capabilities registers */

diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 59a21c9..76a630b 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -122,13 +122,24 @@ static void vlv_psr_setup_vsc(struct intel_dp *intel_dp)
  static void skl_psr_setup_su_vsc(struct intel_dp *intel_dp)
  {
struct edp_vsc_psr psr_vsc;
+   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+   struct drm_device *dev = intel_dig_port->base.base.dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
  
  	/* Prepare VSC Header for SU as per EDP 1.4 spec, Table 6.11 */

memset(_vsc, 0, sizeof(psr_vsc));
psr_vsc.sdp_header.HB0 = 0;
psr_vsc.sdp_header.HB1 = 0x7;
psr_vsc.sdp_header.HB2 = 0x3;
-   psr_vsc.sdp_header.HB3 = 0xb;
+   psr_vsc.sdp_header.HB3 = 0xc;
+   if (dev_priv->psr.y_cord_support &&
+   dev_priv->psr.colorimetry_support) {
+   psr_vsc.sdp_header.HB2 = 0x5;
+   psr_vsc.sdp_header.HB3 = 0x13;
+   } else {
+   psr_vsc.sdp_header.HB2 = 0x4;
+   psr_vsc.sdp_header.HB3 = 0xe;
+   }

That looks bogus. Why do we claim to have colorimetry data but
then don't fill it out?

HB2  to be set  04 or 05
04h = 3D stereo + PSR/PSR2 + Y-coordinate.
05h = 3D stereo- + PSR/PSR2 + Y-coordinate + Pixel Encoding/Colorimetry 
Format


As of now it's defaulting to 0x4, will correct it.


Also you're not setting the actual y coordinate stuff anywhere, so why
would we want to indicate that we support it?

Bspec says to set CHICKEN_TRANS_EDP(0x420cc) bit 15 if Y coordinate is 
supported.

it set in patch 2.

intel_psr_write_vsc(intel_dp, _vsc);
  }
  
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h

index 63b8bd5..3d875c0 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -194,7 +194,7 @@
  # define DP_PSR_SETUP_TIME_0(6 << 1)
  # define DP_PSR_SETUP_TIME_MASK (7 << 1)
  # define DP_PSR_SETUP_TIME_SHIFT1
-
+# define DP_PSR_Y_COORDINATE   (1 << 4)
  /*
   * 0x80-0x8f describe downstream port capabilities, but there are two layouts

Re: [Intel-gfx] [PATCH v3] drm/i915/dp: DP audio API changes for MST

[Pandiyan, Dhinakaran]

On Thu, 2016-08-11 at 10:39 +0300, Ville Syrjälä wrote:
> On Thu, Aug 11, 2016 at 07:10:39AM +, Pandiyan, Dhinakaran wrote:
> > On Thu, 2016-08-11 at 09:26 +0300, Ville Syrjälä wrote:
> > > On Wed, Aug 10, 2016 at 12:41:57PM -0700, Dhinakaran Pandiyan wrote:
> > > > DP MST provides the capability to send multiple video and audio streams
> > > > through a single port. This requires the API's between i915 and audio
> > > > drivers to distinguish between multiple audio capable displays that can 
> > > > be
> > > > connected to a port. Currently only the port identity is shared in the
> > > > APIs. This patch adds support for MST with an additional parameter
> > > > 'int pipe'.  The existing parameter 'port' does not change it's meaning.
> > > > 
> > > > pipe =
> > > > MST : display pipe that the stream originates from
> > > > Non-MST : -1
> > > > 
> > > > Affected APIs:
> > > > struct i915_audio_component_ops
> > > > -   int (*sync_audio_rate)(struct device *, int port, int rate);
> > > > +   int (*sync_audio_rate)(struct device *, int port, int pipe,
> > > > +int rate);
> > > > 
> > > > -   int (*get_eld)(struct device *, int port, bool *enabled,
> > > > -   unsigned char *buf, int max_bytes);
> > > > +   int (*get_eld)(struct device *, int port, int pipe,
> > > > +  bool *enabled, unsigned char *buf, int 
> > > > max_bytes);
> > > > 
> > > > struct i915_audio_component_audio_ops
> > > > -   void (*pin_eld_notify)(void *audio_ptr, int port);
> > > > +   void (*pin_eld_notify)(void *audio_ptr, int port, int pipe);
> > > > 
> > > > This patch makes dummy changes in the audio drivers (Libin) for build to
> > > > succeed. The audio side drivers will send the right 'pipe' values in
> > > > patches that will follow.
> > > > 
> > > > v2:
> > > > Renamed the new API parameter from 'dev_id' to 'pipe'. (Jim, Ville)
> > > > Included Asoc driver API compatibility changes from Jeeja.
> > > > Added WARN_ON() for invalid pipe in get_saved_encoder(). (Takashi)
> > > > Added comment for av_enc_map[] definition. (Takashi)
> > > > 
> > > > v3:
> > > > Fixed logic error introduced while renaming 'dev_id' as 'pipe' (Ville)
> > > > Renamed get_saved_encoder() to get_saved_enc() to reduce line length
> > > > 
> > > > Signed-off-by: Dhinakaran Pandiyan 
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_drv.h|  3 +-
> > > >  drivers/gpu/drm/i915/intel_audio.c | 93 
> > > > ++
> > > >  include/drm/i915_component.h   |  6 +--
> > > >  include/sound/hda_i915.h   | 11 +++--
> > > >  sound/hda/hdac_i915.c  |  9 ++--
> > > >  sound/pci/hda/patch_hdmi.c |  7 +--
> > > >  sound/soc/codecs/hdac_hdmi.c   |  2 +-
> > > >  7 files changed, 86 insertions(+), 45 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > index c36d176..8e4a88f 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > @@ -2036,7 +2036,8 @@ struct drm_i915_private {
> > > > /* perform PHY state sanity checks? */
> > > > bool chv_phy_assert[2];
> > > >  
> > > > -   struct intel_encoder *dig_port_map[I915_MAX_PORTS];
> > > > +   /* Used to save the pipe-to-encoder mapping for audio */
> > > > +   struct intel_encoder *av_enc_map[I915_MAX_PIPES];
> > > >  
> > > > /*
> > > >  * NOTE: This is the dri1/ums dungeon, don't add stuff here. 
> > > > Your patch
> > > > diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> > > > b/drivers/gpu/drm/i915/intel_audio.c
> > > > index ef20875..a7467ea 100644
> > > > --- a/drivers/gpu/drm/i915/intel_audio.c
> > > > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > > > @@ -500,6 +500,7 @@ void intel_audio_codec_enable(struct intel_encoder 
> > > > *intel_encoder)
> > > > struct i915_audio_component *acomp = dev_priv->audio_component;
> > > > struct intel_digital_port *intel_dig_port = 
> > > > enc_to_dig_port(encoder);
> > > > enum port port = intel_dig_port->port;
> > > > +   enum pipe pipe = crtc->pipe;
> > > >  
> > > > connector = drm_select_eld(encoder);
> > > > if (!connector)
> > > > @@ -524,12 +525,18 @@ void intel_audio_codec_enable(struct 
> > > > intel_encoder *intel_encoder)
> > > >  
> > > > mutex_lock(_priv->av_mutex);
> > > > intel_encoder->audio_connector = connector;
> > > > +
> > > > /* referred in audio callbacks */
> > > > -   dev_priv->dig_port_map[port] = intel_encoder;
> > > > +   dev_priv->av_enc_map[pipe] = intel_encoder;
> > > > mutex_unlock(_priv->av_mutex);
> > > >  
> > > > +   /* audio drivers expect pipe = -1 to indicate Non-MST cases */
> > > > +   if (intel_encoder->type != INTEL_OUTPUT_DP_MST)
> > > > +   pipe = -1;
> > > > +
> > > > if 

Re: [Intel-gfx] [PATCH 2/2] Validate modes against available link bandwidth

[Pandiyan, Dhinakaran]

On Thu, 2016-08-11 at 16:41 -0700, Anusha Srivatsa wrote:
> drm/dp/mst/i915
> 
> Signed-off-by: Anusha Srivatsa 
> 
> Validate the modes against available link bandwidth rather than
> maximum link bandwidth so that we have a better idea as to whether
> a proposed mode can truly run beside existing stream.

The Signed-off line follows the explanation body.
https://www.kernel.org/doc/Documentation/SubmittingPatches

> ---
>  drivers/gpu/drm/i915/intel_dp_mst.c | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index 629337d..e7e87d7 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -352,13 +352,23 @@ static enum drm_mode_status
>  intel_dp_mst_mode_valid(struct drm_connector *connector,
>   struct drm_display_mode *mode)
>  {
> + int req_pbn = 0;
> + int avail_pbn = 0;
> + struct intel_connector *intel_connector = to_intel_connector(connector);
> + struct intel_dp *intel_dp = intel_connector->mst_port;
> + struct drm_dp_mst_topology_mgr *mgr = _dp->mst_mgr;
> + struct drm_dp_mst_port *port = (struct drm_dp_mst_port *) 
> (intel_connector->port);
>   int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
>  
> - /* TODO - validate mode against available PBN for link */
> + avail_pbn = drm_dp_mst_get_avail_pbn(mgr, port);
> + req_pbn = drm_dp_calc_pbn_mode(mode->clock, 24);
> + if (req_pbn > avail_pbn)
> + return MODE_H_ILLEGAL;
> +
>   if (mode->clock < 1)
>   return MODE_CLOCK_LOW;
>  
> - if (mode->flags & DRM_MODE_FLAG_DBLCLK)
> +if (mode->flags & DRM_MODE_FLAG_DBLCLK)
>   return MODE_H_ILLEGAL;
>  
>   if (mode->clock > max_dotclk)

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

Re: [Intel-gfx] [PATCH 1/2] A Helper function that returns available link bandwidth

[Pandiyan, Dhinakaran]

On Thu, 2016-08-11 at 16:41 -0700, Anusha Srivatsa wrote:
> drm/dp/mst
> 
> Signed-off-by: Anusha Srivatsa 
> 
> Add a function that returns the available link bandwidth for
> MST port so that we can accurately determine whether a new
> mode is valid for the link or not.
> 

The Signed-off line should follow the explanation body.

> Cc: dri-de...@lists.freedesktop.org
> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 12 
>  include/drm/drm_dp_mst_helper.h   |  1 +
>  2 files changed, 13 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 04e4571..7a239f6 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -43,6 +43,8 @@ static bool dump_dp_payload_table(struct 
> drm_dp_mst_topology_mgr *mgr,
> char *buf);
>  static int test_calc_pbn_mode(void);
>  
> +int drm_dp_mst_get_avail_pbn(struct drm_dp_mst_topology_mgr *mgr, struct 
> drm_dp_mst_port *port);
> +
>  static void drm_dp_put_port(struct drm_dp_mst_port *port);
>  
>  static int drm_dp_dpcd_write_payload(struct drm_dp_mst_topology_mgr *mgr,
> @@ -2730,6 +2732,16 @@ static int test_calc_pbn_mode(void)
>   return 0;
>  }
>  
> +int drm_dp_mst_get_avail_pbn(struct drm_dp_mst_topology_mgr *mgr, struct 
> drm_dp_mst_port *port)
> +{
> +port = drm_dp_get_validated_port_ref(mgr,port);
> +if (port)
> +return port->available_pbn;
> +
> +return -EINVAL;
> +}
> +EXPORT_SYMBOL(drm_dp_mst_get_avail_pbn);
> +
>  /* we want to kick the TX after we've ack the up/down IRQs. */
>  static void drm_dp_mst_kick_tx(struct drm_dp_mst_topology_mgr *mgr)
>  {
> diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
> index 0032076..74dc4ab 100644
> --- a/include/drm/drm_dp_mst_helper.h
> +++ b/include/drm/drm_dp_mst_helper.h
> @@ -576,6 +576,7 @@ struct edid *drm_dp_mst_get_edid(struct drm_connector 
> *connector, struct drm_dp_
>  
>  int drm_dp_calc_pbn_mode(int clock, int bpp);
>  
> +int drm_dp_mst_get_avail_pbn(struct drm_dp_mst_topology_mgr *mgr, struct 
> drm_dp_mst_port *port);
>  
>  bool drm_dp_mst_allocate_vcpi(struct drm_dp_mst_topology_mgr *mgr, struct 
> drm_dp_mst_port *port, int pbn, int *slots);
>  

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

Re: [Intel-gfx] [PATCH v2] drm/i915: intel_dp_link_is_valid() should only return status of link

[Pandiyan, Dhinakaran]

On Thu, 2016-08-11 at 15:23 -0700, Manasi Navare wrote:
> Intel_dp_link_is_valid() function reads the Link status registers
> and returns a boolean to indicate link is valid or not.
> If the link has lost lock and is not valid any more, link
> training is performed outside the function else previously trained link
> is retained.
> This gives us flexibility of checking whether link is valid and training
> it independently.
> 
> v2:
> * Changed the function name from intel_dp_check_link_status()
> to intel_dp_link_is_valid()  (Lukas Wunner)
> * Checks for CRTC and active CRTC are moved outside the
> intel_dp_link_is_valid() function (Rodrigo Vivi)
> 
> Signed-off-by: Manasi Navare 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 56 
> +++--
>  1 file changed, 37 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 364db90..891147d 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3881,36 +3881,33 @@ go_again:
>   return -EINVAL;
>  }
>  
> -static void
> -intel_dp_check_link_status(struct intel_dp *intel_dp)
> +static bool
> +intel_dp_link_is_valid(struct intel_dp *intel_dp)
>  {
> - struct intel_encoder *intel_encoder = _to_dig_port(intel_dp)->base;
>   struct drm_device *dev = intel_dp_to_dev(intel_dp);
>   u8 link_status[DP_LINK_STATUS_SIZE];
>  
>   WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
>  
>   if (!intel_dp_get_link_status(intel_dp, link_status)) {
> - DRM_ERROR("Failed to get link status\n");
> - return;
> + DRM_DEBUG_KMS("Failed to get link status\n");
> + return false;
>   }
>  
> - if (!intel_encoder->base.crtc)
> - return;
> + /* Check if the link is valid by reading the bits of Link status
> +  * registers
> +  */
> + if (!drm_dp_channel_eq_ok(link_status, intel_dp->lane_count)) {
> + DRM_DEBUG_KMS("Channel EQ or CR not ok, need to retrain\n");
drm_dp_channel_eq_ok() does not check for CR. Should we just say
"Channel EQ not ok" to preempt ambiguity while debugging ?

> + return false;
> + }
>  
> - if (!to_intel_crtc(intel_encoder->base.crtc)->active)
> - return;
> + DRM_DEBUG_KMS("Link is good, no need to retrain\n");
The caller does not expect us to link train anymore, I don't think we
have to explicitly state "no need to retrain". Also, do we need debug
messages if the link is good?

> + return true;
>  
> - /* if link training is requested we should perform it always */
> - if ((intel_dp->compliance_test_type == DP_TEST_LINK_TRAINING) ||
> - (!drm_dp_channel_eq_ok(link_status, intel_dp->lane_count))) {
> - DRM_DEBUG_KMS("%s: channel EQ not ok, retraining\n",
> -   intel_encoder->base.name);
> - intel_dp_start_link_train(intel_dp);
> - intel_dp_stop_link_train(intel_dp);
> - }
>  }
>  
> +
>  /*
>   * According to DP spec
>   * 5.1.2:
> @@ -3928,6 +3925,8 @@ static bool
>  intel_dp_short_pulse(struct intel_dp *intel_dp)
>  {
>   struct drm_device *dev = intel_dp_to_dev(intel_dp);
> + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> + struct intel_encoder *intel_encoder = _dig_port->base;
>   u8 sink_irq_vector = 0;
>   u8 old_sink_count = intel_dp->sink_count;
>   bool ret;
> @@ -3968,8 +3967,18 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
>   DRM_DEBUG_DRIVER("CP or sink specific irq unhandled\n");
>   }
>  
> + /* Do not train the link if there is no crtc */
> + if (!intel_encoder->base.crtc)
> + return true;
> + if (!to_intel_crtc(intel_encoder->base.crtc)->active)
> + return true;
> +
I might be completely off base here. Shouldn't we keep the link valid
irrespective of whether there is an active crtc? I thought that is what
the refactoring is supposed to enable. Does intel_dp_short_pulse() get
called when there is a link loss during upfront link training? And in
that case, shouldn't we retrain even without a crtc? 

Besides that, how about using just one return?

struct drm_crtc *crtc = intel_encoder->base.crtc;

if (crtc == NULL || !to_intel_crtc(crtc)->active)
return true;


>   drm_modeset_lock(>mode_config.connection_mutex, NULL);
> - intel_dp_check_link_status(intel_dp);
> + if (!intel_dp_link_is_valid(intel_dp) ||
> + intel_dp->compliance_test_type == DP_TEST_LINK_TRAINING) {
> + intel_dp_start_link_train(intel_dp);
> + intel_dp_stop_link_train(intel_dp);
> + }
>   drm_modeset_unlock(>mode_config.connection_mutex);
>  
>   return true;
> @@ -4298,8 +4307,17 @@ intel_dp_long_pulse(struct intel_connector 
> *intel_connector)
>* check links status, there has been known 

[Intel-gfx] [PATCH] Revert "drm/i915/chv: Set min freq to efficient frequency on chv"

[deepak . s]

From: Deepak S 

With latest Punit FW, vgg input voltag drop falling to minimum is fixed.
So reverting the WA patch & moving to turbo freq opreation range to [RPn -> RP0]

This reverts commit 5b7c91b78b1ce6663e0f1f037f6cb4d7c9537d44.

commit 5b7c91b78b1ce6663e0f1f037f6cb4d7c9537d44
Author: Deepak S 
Date:   Sat May 9 18:15:46 2015 +0530

drm/i915/chv: Set min freq to efficient frequency on chv

Signed-off-by: Deepak S 
---
 drivers/gpu/drm/i915/intel_pm.c | 21 +++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 81ab119..e59799a 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5579,6 +5579,24 @@ static int cherryview_rps_guar_freq(struct 
drm_i915_private *dev_priv)
return rp1;
 }
 
+static int cherryview_rps_min_freq(struct drm_i915_private *dev_priv)
+{
+   struct drm_device *dev = _priv->drm;
+   u32 val, rpn;
+
+   if (dev->pdev->revision >= 0x20) {
+   val = vlv_punit_read(dev_priv, FB_GFX_FMIN_AT_VMIN_FUSE);
+   rpn = ((val >> FB_GFX_FMIN_AT_VMIN_FUSE_SHIFT) &
+  FB_GFX_FREQ_FUSE_MASK);
+   } else { /* For pre-production hardware */
+   val = vlv_punit_read(dev_priv, PUNIT_GPU_STATUS_REG);
+   rpn = ((val >> PUNIT_GPU_STATIS_GFX_MIN_FREQ_SHIFT) &
+  PUNIT_GPU_STATUS_GFX_MIN_FREQ_MASK);
+   }
+
+   return rpn;
+}
+
 static int valleyview_rps_guar_freq(struct drm_i915_private *dev_priv)
 {
u32 val, rp1;
@@ -5818,8 +5836,7 @@ static void cherryview_init_gt_powersave(struct 
drm_i915_private *dev_priv)
 intel_gpu_freq(dev_priv, dev_priv->rps.rp1_freq),
 dev_priv->rps.rp1_freq);
 
-   /* PUnit validated range is only [RPe, RP0] */
-   dev_priv->rps.min_freq = dev_priv->rps.efficient_freq;
+   dev_priv->rps.min_freq = cherryview_rps_min_freq(dev_priv);
DRM_DEBUG_DRIVER("min GPU freq: %d MHz (%u)\n",
 intel_gpu_freq(dev_priv, dev_priv->rps.min_freq),
 dev_priv->rps.min_freq);
-- 
1.9.1

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

[Intel-gfx] [PATCH 2/2] Validate modes against available link bandwidth

[Anusha Srivatsa]

drm/dp/mst/i915

Signed-off-by: Anusha Srivatsa 

Validate the modes against available link bandwidth rather than
maximum link bandwidth so that we have a better idea as to whether
a proposed mode can truly run beside existing stream.
---
 drivers/gpu/drm/i915/intel_dp_mst.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 629337d..e7e87d7 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -352,13 +352,23 @@ static enum drm_mode_status
 intel_dp_mst_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
 {
+   int req_pbn = 0;
+   int avail_pbn = 0;
+   struct intel_connector *intel_connector = to_intel_connector(connector);
+   struct intel_dp *intel_dp = intel_connector->mst_port;
+   struct drm_dp_mst_topology_mgr *mgr = _dp->mst_mgr;
+   struct drm_dp_mst_port *port = (struct drm_dp_mst_port *) 
(intel_connector->port);
int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
 
-   /* TODO - validate mode against available PBN for link */
+   avail_pbn = drm_dp_mst_get_avail_pbn(mgr, port);
+   req_pbn = drm_dp_calc_pbn_mode(mode->clock, 24);
+   if (req_pbn > avail_pbn)
+   return MODE_H_ILLEGAL;
+
if (mode->clock < 1)
return MODE_CLOCK_LOW;
 
-   if (mode->flags & DRM_MODE_FLAG_DBLCLK)
+if (mode->flags & DRM_MODE_FLAG_DBLCLK)
return MODE_H_ILLEGAL;
 
if (mode->clock > max_dotclk)
-- 
2.7.4

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

[Intel-gfx] [PATCH 1/2] A Helper function that returns available link bandwidth

[Anusha Srivatsa]

drm/dp/mst

Signed-off-by: Anusha Srivatsa 

Add a function that returns the available link bandwidth for
MST port so that we can accurately determine whether a new
mode is valid for the link or not.

Cc: dri-de...@lists.freedesktop.org
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 12 
 include/drm/drm_dp_mst_helper.h   |  1 +
 2 files changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 04e4571..7a239f6 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -43,6 +43,8 @@ static bool dump_dp_payload_table(struct 
drm_dp_mst_topology_mgr *mgr,
  char *buf);
 static int test_calc_pbn_mode(void);
 
+int drm_dp_mst_get_avail_pbn(struct drm_dp_mst_topology_mgr *mgr, struct 
drm_dp_mst_port *port);
+
 static void drm_dp_put_port(struct drm_dp_mst_port *port);
 
 static int drm_dp_dpcd_write_payload(struct drm_dp_mst_topology_mgr *mgr,
@@ -2730,6 +2732,16 @@ static int test_calc_pbn_mode(void)
return 0;
 }
 
+int drm_dp_mst_get_avail_pbn(struct drm_dp_mst_topology_mgr *mgr, struct 
drm_dp_mst_port *port)
+{
+port = drm_dp_get_validated_port_ref(mgr,port);
+if (port)
+return port->available_pbn;
+
+return -EINVAL;
+}
+EXPORT_SYMBOL(drm_dp_mst_get_avail_pbn);
+
 /* we want to kick the TX after we've ack the up/down IRQs. */
 static void drm_dp_mst_kick_tx(struct drm_dp_mst_topology_mgr *mgr)
 {
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index 0032076..74dc4ab 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -576,6 +576,7 @@ struct edid *drm_dp_mst_get_edid(struct drm_connector 
*connector, struct drm_dp_
 
 int drm_dp_calc_pbn_mode(int clock, int bpp);
 
+int drm_dp_mst_get_avail_pbn(struct drm_dp_mst_topology_mgr *mgr, struct 
drm_dp_mst_port *port);
 
 bool drm_dp_mst_allocate_vcpi(struct drm_dp_mst_topology_mgr *mgr, struct 
drm_dp_mst_port *port, int pbn, int *slots);
 
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH 03/23] drm/i915: Move HAS_RUNTIME_PM definition to platform

[Carlos Santa]

On Tue, 2016-08-09 at 16:49 +0300, Ville Syrjälä wrote:
> On Thu, Jul 21, 2016 at 04:34:28PM +0300, Imre Deak wrote:
> > On ke, 2016-07-20 at 13:25 -0700, Rodrigo Vivi wrote:
> > > On Wed, Jul 20, 2016 at 10:40 AM, Carlos Santa  wrote:
> > > > Moving all GPU features to the platform struct definition allows for
> > > > - standard place when adding new features from new platforms
> > > > - possible to see supported features when dumping struct
> > > >   definitions
> > > > 
> > > > Signed-off-by: Carlos Santa 
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_drv.h | 6 ++
> > > >  drivers/gpu/drm/i915/i915_pci.c | 7 ++-
> > > >  2 files changed, 8 insertions(+), 5 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > index 6569eb7..7443b9a 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > @@ -769,6 +769,7 @@ struct intel_csr {
> > > > func(is_preliminary) sep \
> > > > func(has_fbc) sep \
> > > > func(has_psr) sep \
> > > > +   func(has_runtime_pm) sep \
> > > > func(has_pipe_cxsr) sep \
> > > > func(has_hotplug) sep \
> > > > func(cursor_needs_physical) sep \
> > > > @@ -2848,10 +2849,7 @@ struct drm_i915_cmd_table {
> > > >  #define HAS_DDI(dev)   (INTEL_INFO(dev)->has_ddi)
> > > >  #define HAS_FPGA_DBG_UNCLAIMED(dev)(INTEL_INFO(dev)->has_fpga_dbg)
> > > >  #define HAS_PSR(dev)   (INTEL_INFO(dev)->has_psr)
> > > > -#define HAS_RUNTIME_PM(dev)(IS_GEN6(dev) || IS_HASWELL(dev) || \
> > > > -IS_BROADWELL(dev) || 
> > > > IS_VALLEYVIEW(dev) || \
> > > > -IS_CHERRYVIEW(dev) || IS_SKYLAKE(dev) 
> > > > || \
> > > > -IS_KABYLAKE(dev) || IS_BROXTON(dev))
> > > 
> > > Why don't we have runtime_pm on Ivybridge since we have on
> > > sandybdrige? Imre, any idea?
> > 
> > I don't know what are the exact differences, in any case I haven't
> > tried to enable RPM on IVB. I think Ville had plans for this.
> 
> I tried it, it gave zero benefit with the downside of killing HPD. So
> I've changed my mind and now I want to see the SNB runtime PM support
> removed instead. So runtime PM would be only for HSW+/VLV/CHV.

V3 of this patch series already does this.

> 
> And we still need to fix HPD while runtime suspended. But at least
> it's theoretically possible for those platforms. I don't think we can
> do it for SNB/IVB and older machines. And polling is no answer as
> it just increases the power consumption. So adding ineffective
> runtime PM with HPD polling is just wasting more power than not
> runtime suspending in the first place.
> 
> > 
> > --Imre
> > 
> > > 
> > > > +#define HAS_RUNTIME_PM(dev)(INTEL_INFO(dev)->has_runtime_pm)
> > > >  #define HAS_RC6(dev)   (INTEL_INFO(dev)->gen >= 6)
> > > >  #define HAS_RC6p(dev)  (IS_GEN6(dev) || IS_IVYBRIDGE(dev))
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_pci.c 
> > > > b/drivers/gpu/drm/i915/i915_pci.c
> > > > index 8b1311d..92ab3c2 100644
> > > > --- a/drivers/gpu/drm/i915/i915_pci.c
> > > > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > > > @@ -198,6 +198,7 @@ static const struct intel_device_info 
> > > > intel_ironlake_m_info = {
> > > > .gen = 6, .num_pipes = 2, \
> > > > .need_gfx_hws = 1, .has_hotplug = 1, \
> > > > .has_fbc = 1, \
> > > > +   .has_runtime_pm = 1, \
> > > 
> > > This patch made me notice that we should define the
> > > 
> > > GEN7_FEATURE on GEN6_FEATURES + new changes as a followup of patch
> > > 02/32 or in that same patch.
> > > However for this case we should redefine .has_runtime_pm=0 on gen7,
> > > what is really strange.
> > > 
> > > Anyway, this patch itself has nothing wrong and just follows what it
> > > was set there already.
> > > any change related to my comments should be addressed in separated 
> > > patches.
> > > So fell free to also use
> > > Reviewed-by: Rodrigo Vivi 
> > > 
> > > > .ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
> > > > .has_llc = 1, \
> > > > GEN_DEFAULT_PIPEOFFSETS, \
> > > > @@ -241,6 +242,7 @@ static const struct intel_device_info 
> > > > intel_ivybridge_q_info = {
> > > >  #define VLV_FEATURES  \
> > > > .gen = 7, .num_pipes = 2, \
> > > > .has_psr = 1, \
> > > > +   .has_runtime_pm = 1, \
> > > > .need_gfx_hws = 1, .has_hotplug = 1, \
> > > > .ring_mask = RENDER_RING | BSD_RING | BLT_RING, \
> > > > .display_mmio_offset = VLV_DISPLAY_BASE, \
> > > > @@ -263,7 +265,8 @@ static const struct intel_device_info 
> > > > intel_valleyview_d_info = {
> > > > .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING, \
> > > > .has_ddi = 1, \
> > > > .has_fpga_dbg = 1, \
> > > > -   .has_psr 

Re: [Intel-gfx] drm/fb-helper: Reduce READ_ONCE(master) to lockless_dereference

[Paul E. McKenney]

On Thu, Aug 11, 2016 at 11:44:08AM +0200, Peter Zijlstra wrote:
> On Wed, Jun 22, 2016 at 08:46:12AM +0100, Chris Wilson wrote:
> > We are only documenting that the read is outside of the lock, and do not
> > require strict ordering on the operation. In this case the more relaxed
> > lockless_dereference() will suffice.
> 
> No, no, no... This is 'broken'. lockless_dereference() is _stronger_
> than READ_ONCE(), not weaker.
> 
> lockless_dereference() is a wrapper around smp_read_barrier_depends()
> and is used to form read dependencies. There is no read dependency here,
> therefore using lockless_dereference() is entirely pointless.
> 
> Look at the definition of lockless_dereference(), it does a READ_ONCE()
> and then smp_read_barrier_depends().
> 
> Also, clue is in the name: 'dereference', you don't actually dereference
> the pointer here, only load it.

What Peter said!

If you are just checking the value of an RCU-protected pointer,
that is, one on which you would use rcu_dereference() rather than
lockless_dereference(), rcu_access_pointer() does the job of READ_ONCE()
while keeping sparse happy.

Thanx, Paul

> > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > @@ -464,7 +464,7 @@ static bool drm_fb_helper_is_bound(struct drm_fb_helper 
> > *fb_helper)
> >  
> > /* Sometimes user space wants everything disabled, so don't steal the
> >  * display if there's a master. */
> > -   if (READ_ONCE(dev->master))
> > +   if (lockless_dereference(dev->master))
> > return false;
> >  
> > drm_for_each_crtc(crtc, dev) {
> 

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

Re: [Intel-gfx] [PATCH 1/2] Revert "drm/fb-helper: Reduce READ_ONCE(master) to lockless_dereference"

[Paul E. McKenney]

On Thu, Aug 11, 2016 at 12:38:59PM +0200, Daniel Vetter wrote:
> On Thu, Aug 11, 2016 at 11:50:21AM +0200, Johannes Berg wrote:
> > From: Johannes Berg 
> > 
> > This reverts commit fa7d81bb3c269a2ee38b6e4d569d9eb8be1a78ad.
> > 
> > As Peter explained:
> >   [...] lockless_dereference() is _stronger_ than READ_ONCE(), not weaker.
> > 
> >   [...]
> > 
> >   Also, clue is in the name: 'dereference', you don't actually dereference
> >   the pointer here, only load it.
> > 
> > My next patch breaks compile on this, because it assumes you want to
> > deference and thus also need the struct type visible (which it isn't
> > here), so revert it.
> > 
> > Cc: Peter Zijlstra 
> > Signed-off-by: Johannes Berg 
> 
> Reviewed-by: Daniel Vetter 
> 
> And ack-by: me for merging through whatever tree this makes sense for.
> -Daniel

Initial testing says that the change below must precede the change
to the definition of lockless_dereference(), so the two should go
together.

If my upcoming testing of the two changes together pans out, I will
give you a Tested-by -- I am guessing that you don't want to wait
until the next merge window for these changes.

Thanx, Paul

> > ---
> >  drivers/gpu/drm/drm_fb_helper.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c 
> > b/drivers/gpu/drm/drm_fb_helper.c
> > index ce54e985d91b..0a06f9120b5a 100644
> > --- a/drivers/gpu/drm/drm_fb_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > @@ -464,7 +464,7 @@ static bool drm_fb_helper_is_bound(struct drm_fb_helper 
> > *fb_helper)
> >  
> > /* Sometimes user space wants everything disabled, so don't steal the
> >  * display if there's a master. */
> > -   if (lockless_dereference(dev->master))
> > +   if (READ_ONCE(dev->master))
> > return false;
> >  
> > drm_for_each_crtc(crtc, dev) {
> > -- 
> > 2.8.1
> > 
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> 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 v2] drm/i915: intel_dp_link_is_valid() should only return status of link

[Manasi Navare]

Intel_dp_link_is_valid() function reads the Link status registers
and returns a boolean to indicate link is valid or not.
If the link has lost lock and is not valid any more, link
training is performed outside the function else previously trained link
is retained.
This gives us flexibility of checking whether link is valid and training
it independently.

v2:
* Changed the function name from intel_dp_check_link_status()
to intel_dp_link_is_valid()  (Lukas Wunner)
* Checks for CRTC and active CRTC are moved outside the
intel_dp_link_is_valid() function (Rodrigo Vivi)

Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/i915/intel_dp.c | 56 +++--
 1 file changed, 37 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 364db90..891147d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3881,36 +3881,33 @@ go_again:
return -EINVAL;
 }
 
-static void
-intel_dp_check_link_status(struct intel_dp *intel_dp)
+static bool
+intel_dp_link_is_valid(struct intel_dp *intel_dp)
 {
-   struct intel_encoder *intel_encoder = _to_dig_port(intel_dp)->base;
struct drm_device *dev = intel_dp_to_dev(intel_dp);
u8 link_status[DP_LINK_STATUS_SIZE];
 
WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
 
if (!intel_dp_get_link_status(intel_dp, link_status)) {
-   DRM_ERROR("Failed to get link status\n");
-   return;
+   DRM_DEBUG_KMS("Failed to get link status\n");
+   return false;
}
 
-   if (!intel_encoder->base.crtc)
-   return;
+   /* Check if the link is valid by reading the bits of Link status
+* registers
+*/
+   if (!drm_dp_channel_eq_ok(link_status, intel_dp->lane_count)) {
+   DRM_DEBUG_KMS("Channel EQ or CR not ok, need to retrain\n");
+   return false;
+   }
 
-   if (!to_intel_crtc(intel_encoder->base.crtc)->active)
-   return;
+   DRM_DEBUG_KMS("Link is good, no need to retrain\n");
+   return true;
 
-   /* if link training is requested we should perform it always */
-   if ((intel_dp->compliance_test_type == DP_TEST_LINK_TRAINING) ||
-   (!drm_dp_channel_eq_ok(link_status, intel_dp->lane_count))) {
-   DRM_DEBUG_KMS("%s: channel EQ not ok, retraining\n",
- intel_encoder->base.name);
-   intel_dp_start_link_train(intel_dp);
-   intel_dp_stop_link_train(intel_dp);
-   }
 }
 
+
 /*
  * According to DP spec
  * 5.1.2:
@@ -3928,6 +3925,8 @@ static bool
 intel_dp_short_pulse(struct intel_dp *intel_dp)
 {
struct drm_device *dev = intel_dp_to_dev(intel_dp);
+   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+   struct intel_encoder *intel_encoder = _dig_port->base;
u8 sink_irq_vector = 0;
u8 old_sink_count = intel_dp->sink_count;
bool ret;
@@ -3968,8 +3967,18 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
DRM_DEBUG_DRIVER("CP or sink specific irq unhandled\n");
}
 
+   /* Do not train the link if there is no crtc */
+   if (!intel_encoder->base.crtc)
+   return true;
+   if (!to_intel_crtc(intel_encoder->base.crtc)->active)
+   return true;
+
drm_modeset_lock(>mode_config.connection_mutex, NULL);
-   intel_dp_check_link_status(intel_dp);
+   if (!intel_dp_link_is_valid(intel_dp) ||
+   intel_dp->compliance_test_type == DP_TEST_LINK_TRAINING) {
+   intel_dp_start_link_train(intel_dp);
+   intel_dp_stop_link_train(intel_dp);
+   }
drm_modeset_unlock(>mode_config.connection_mutex);
 
return true;
@@ -4298,8 +4307,17 @@ intel_dp_long_pulse(struct intel_connector 
*intel_connector)
 * check links status, there has been known issues of
 * link loss triggerring long pulse
 */
+   /* Do not train the link if there is no crtc */
+   if (!intel_encoder->base.crtc)
+   goto out;
+   if (!to_intel_crtc(intel_encoder->base.crtc)->active)
+   goto out;
+
drm_modeset_lock(>mode_config.connection_mutex, NULL);
-   intel_dp_check_link_status(intel_dp);
+   if (!intel_dp_link_is_valid(intel_dp)) {
+   intel_dp_start_link_train(intel_dp);
+   intel_dp_stop_link_train(intel_dp);
+   }
drm_modeset_unlock(>mode_config.connection_mutex);
goto out;
}
-- 
1.9.1

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

[Intel-gfx] [PATCH v2] drm/i915/dp: Switch to using the DRM function for reading DP link status

[Dhinakaran Pandiyan]

Since a DRM function that reads link DP link status is available, let's
use that instead of the i915 clone.

drm_dp_dpcd_read_link_status() returns a negative error code if the number
of bytes read is not DP_LINK_STATUS_SIZE, drm_dp_dpcd_access() does the
length check.

Signed-off-by: Dhinakaran Pandiyan 

v2: Eliminated redundant DP_LINK_STATUS_SIZE length check.
---
 drivers/gpu/drm/i915/intel_dp.c   | 15 ++-
 drivers/gpu/drm/i915/intel_dp_link_training.c |  8 ++--
 drivers/gpu/drm/i915/intel_drv.h  |  2 --
 3 files changed, 8 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 8fe2afa..8eff57e 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2863,17 +2863,6 @@ static void chv_dp_post_pll_disable(struct intel_encoder 
*encoder)
chv_phy_post_pll_disable(encoder);
 }
 
-/*
- * Fetch AUX CH registers 0x202 - 0x207 which contain
- * link status information
- */
-bool
-intel_dp_get_link_status(struct intel_dp *intel_dp, uint8_t 
link_status[DP_LINK_STATUS_SIZE])
-{
-   return drm_dp_dpcd_read(_dp->aux, DP_LANE0_1_STATUS, link_status,
-   DP_LINK_STATUS_SIZE) == DP_LINK_STATUS_SIZE;
-}
-
 /* These are source-specific values. */
 uint8_t
 intel_dp_voltage_max(struct intel_dp *intel_dp)
@@ -3896,8 +3885,8 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
 
WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
 
-   if (!intel_dp_get_link_status(intel_dp, link_status)) {
-   DRM_ERROR("Failed to get link status\n");
+   if (drm_dp_dpcd_read_link_status(_dp->aux, link_status) <= 0) {
+   DRM_ERROR("failed to get link status\n");
return;
}
 
diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
b/drivers/gpu/drm/i915/intel_dp_link_training.c
index 60fb39c..8e60e7c 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -150,7 +150,9 @@ intel_dp_link_training_clock_recovery(struct intel_dp 
*intel_dp)
uint8_t link_status[DP_LINK_STATUS_SIZE];
 
drm_dp_link_train_clock_recovery_delay(intel_dp->dpcd);
-   if (!intel_dp_get_link_status(intel_dp, link_status)) {
+
+   if (drm_dp_dpcd_read_link_status(_dp->aux, link_status)
+<= 0) {
DRM_ERROR("failed to get link status\n");
break;
}
@@ -258,7 +260,9 @@ intel_dp_link_training_channel_equalization(struct intel_dp 
*intel_dp)
}
 
drm_dp_link_train_channel_eq_delay(intel_dp->dpcd);
-   if (!intel_dp_get_link_status(intel_dp, link_status)) {
+
+   if (drm_dp_dpcd_read_link_status(_dp->aux, link_status)
+<= 0) {
DRM_ERROR("failed to get link status\n");
break;
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index b1fc67e..a3a2cb9 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1394,8 +1394,6 @@ intel_dp_pre_emphasis_max(struct intel_dp *intel_dp, 
uint8_t voltage_swing);
 void intel_dp_compute_rate(struct intel_dp *intel_dp, int port_clock,
   uint8_t *link_bw, uint8_t *rate_select);
 bool intel_dp_source_supports_hbr2(struct intel_dp *intel_dp);
-bool
-intel_dp_get_link_status(struct intel_dp *intel_dp, uint8_t 
link_status[DP_LINK_STATUS_SIZE]);
 
 static inline unsigned int intel_dp_unused_lane_mask(int lane_count)
 {
-- 
2.5.0

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

[Intel-gfx] [PATCH v11 2/7] drm/i915/skl: Add support for the SAGV, fix underrun hangs

[Lyude]

Since the watermark calculations for Skylake are still broken, we're apt
to hitting underruns very easily under multi-monitor configurations.
While it would be lovely if this was fixed, it's not. Another problem
that's been coming from this however, is the mysterious issue of
underruns causing full system hangs. An easy way to reproduce this with
a skylake system:

- Get a laptop with a skylake GPU, and hook up two external monitors to
  it
- Move the cursor from the built-in LCD to one of the external displays
  as quickly as you can
- You'll get a few pipe underruns, and eventually the entire system will
  just freeze.

After doing a lot of investigation and reading through the bspec, I
found the existence of the SAGV, which is responsible for adjusting the
system agent voltage and clock frequencies depending on how much power
we need. According to the bspec:

"The display engine access to system memory is blocked during the
 adjustment time. SAGV defaults to enabled. Software must use the
 GT-driver pcode mailbox to disable SAGV when the display engine is not
 able to tolerate the blocking time."

The rest of the bspec goes on to explain that software can simply leave
the SAGV enabled, and disable it when we use interlaced pipes/have more
then one pipe active.

Sure enough, with this patchset the system hangs resulting from pipe
underruns on Skylake have completely vanished on my T460s. Additionally,
the bspec mentions turning off the SAGV with more then one pipe enabled
as a workaround for display underruns. While this patch doesn't entirely
fix that, it looks like it does improve the situation a little bit so
it's likely this is going to be required to make watermarks on Skylake
fully functional.

Changes since v10:
 - Apparently sandybridge_pcode_read actually writes values and reads
   them back, despite it's misleading function name. This means we've
   been doing this mostly wrong and have been writing garbage to the
   SAGV control. Because of this, we no longer attempt to read the SAGV
   status during initialization (since there are no helpers for this).
 - mlankhorst noticed that this patch was breaking on some very early
   pre-release Skylake machines, which apparently don't allow you to
   disable the SAGV. To prevent machines from failing tests due to SAGV
   errors, if the first time we try to control the SAGV results in the
   mailbox indicating an invalid command, we just disable future attempts
   to control the SAGV state by setting dev_priv->skl_sagv_status to
   I915_SKL_SAGV_NOT_CONTROLLED and make a note of it in dmesg.
 - Move mutex_unlock() a little higher in skl_enable_sagv(). This
   doesn't actually fix anything, but lets us release the lock a little
   sooner since we're finished with it.
Changes since v9:
 - Only enable/disable sagv on Skylake
Changes since v8:
 - Add intel_state->modeset guard to the conditional for
   skl_enable_sagv()
Changes since v7:
 - Remove GEN9_SAGV_LOW_FREQ, replace with GEN9_SAGV_IS_ENABLED (that's
   all we use it for anyway)
 - Use GEN9_SAGV_IS_ENABLED instead of 0x1 for clarification
 - Fix a styling error that snuck past me
Changes since v6:
 - Protect skl_enable_sagv() with intel_state->modeset conditional in
   intel_atomic_commit_tail()
Changes since v5:
 - Don't use is_power_of_2. Makes things confusing
 - Don't use the old state to figure out whether or not to
   enable/disable the sagv, use the new one
 - Split the loop in skl_disable_sagv into it's own function
 - Move skl_sagv_enable/disable() calls into intel_atomic_commit_tail()
Changes since v4:
 - Use is_power_of_2 against active_crtcs to check whether we have > 1
   pipe enabled
 - Fix skl_sagv_get_hw_state(): (temp & 0x1) indicates disabled, 0x0
   enabled
 - Call skl_sagv_enable/disable() from pre/post-plane updates
Changes since v3:
 - Use time_before() to compare timeout to jiffies
Changes since v2:
 - Really apply minor style nitpicks to patch this time
Changes since v1:
 - Added comments about this probably being one of the requirements to
   fixing Skylake's watermark issues
 - Minor style nitpicks from Matt Roper
 - Disable these functions on Broxton, since it doesn't have an SAGV

Signed-off-by: Lyude 
Cc: Matt Roper 
Cc: Maarten Lankhorst 
Cc: Daniel Vetter 
Cc: Ville Syrjälä 
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/i915/i915_drv.h  |  7 +++
 drivers/gpu/drm/i915/i915_reg.h  |  4 ++
 drivers/gpu/drm/i915/intel_display.c | 12 +
 drivers/gpu/drm/i915/intel_drv.h |  2 +
 drivers/gpu/drm/i915/intel_pm.c  | 89 
 5 files changed, 114 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7971c76..d74d166 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1945,6 +1945,13 @@ struct drm_i915_private {
  

[Intel-gfx] [PATCH v11 7/7] drm/i915/skl: Update DDB values atomically with wms/plane attrs

[Lyude]

Now that we can hook into update_crtcs and control the order in which we
update CRTCs at each modeset, we can finish the final step of fixing
Skylake's watermark handling by performing DDB updates at the same time
as plane updates and watermark updates.

The first major change in this patch is skl_update_crtcs(), which
handles ensuring that we order each CRTC update in our atomic commits
properly so that they honor the DDB flush order.

The second major change in this patch is the order in which we flush the
pipes. While the previous order may have worked, it can't be used in
this approach since it no longer will do the right thing. For example,
using the old ddb flush order:

We have pipes A, B, and C enabled, and we're disabling C. Initial ddb
allocation looks like this:

|   A   |   B   |xxx|

Since we're performing the ddb updates after performing any CRTC
disablements in intel_atomic_commit_tail(), the space to the right of
pipe B is unallocated.

1. Flush pipes with new allocation contained into old space. None
   apply, so we skip this
2. Flush pipes having their allocation reduced, but overlapping with a
   previous allocation. None apply, so we also skip this
3. Flush pipes that got more space allocated. This applies to A and B,
   giving us the following update order: A, B

This is wrong, since updating pipe A first will cause it to overlap with
B and potentially burst into flames. Our new order (see the code
comments for details) would update the pipes in the proper order: B, A.

As well, we calculate the order for each DDB update during the check
phase, and reference it later in the commit phase when we hit
skl_update_crtcs().

This long overdue patch fixes the rest of the underruns on Skylake.

Changes since v1:
 - Add skl_ddb_entry_write() for cursor into skl_write_cursor_wm()
Changes since v2:
 - Use the method for updating CRTCs that Ville suggested
 - In skl_update_wm(), only copy the watermarks for the crtc that was
   passed to us
Changes since v3:
 - Small comment fix in skl_ddb_allocation_overlaps()

Fixes: 0e8fb7ba7ca5 ("drm/i915/skl: Flush the WM configuration")
Fixes: 8211bd5bdf5e ("drm/i915/skl: Program the DDB allocation")
[omitting CC for stable, since this patch will need to be changed for
such backports first]

Testcase: kms_cursor_legacy
Signed-off-by: Lyude 
Reviewed-by: Maarten Lankhorst 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Radhakrishna Sripada 
Cc: Hans de Goede 
Cc: Matt Roper 
---
 drivers/gpu/drm/i915/intel_display.c | 100 +++--
 drivers/gpu/drm/i915/intel_drv.h |   7 ++
 drivers/gpu/drm/i915/intel_pm.c  | 207 +--
 3 files changed, 144 insertions(+), 170 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 61a45f1..68fdbf0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13348,16 +13348,23 @@ static void verify_wm_state(struct drm_crtc *crtc,
  hw_entry->start, hw_entry->end);
}
 
-   /* cursor */
-   hw_entry = _ddb.plane[pipe][PLANE_CURSOR];
-   sw_entry = _ddb->plane[pipe][PLANE_CURSOR];
-
-   if (!skl_ddb_entry_equal(hw_entry, sw_entry)) {
-   DRM_ERROR("mismatch in DDB state pipe %c cursor "
- "(expected (%u,%u), found (%u,%u))\n",
- pipe_name(pipe),
- sw_entry->start, sw_entry->end,
- hw_entry->start, hw_entry->end);
+   /*
+* cursor
+* If the cursor plane isn't active, we may not have updated it's ddb
+* allocation. In that case since the ddb allocation will be updated
+* once the plane becomes visible, we can skip this check
+*/
+   if (intel_crtc->cursor_addr) {
+   hw_entry = _ddb.plane[pipe][PLANE_CURSOR];
+   sw_entry = _ddb->plane[pipe][PLANE_CURSOR];
+
+   if (!skl_ddb_entry_equal(hw_entry, sw_entry)) {
+   DRM_ERROR("mismatch in DDB state pipe %c cursor "
+ "(expected (%u,%u), found (%u,%u))\n",
+ pipe_name(pipe),
+ sw_entry->start, sw_entry->end,
+ hw_entry->start, hw_entry->end);
+   }
}
 }
 
@@ -14109,6 +14116,72 @@ static void intel_update_crtcs(struct drm_atomic_state 
*state,
}
 }
 
+static void skl_update_crtcs(struct drm_atomic_state *state,
+unsigned int *crtc_vblank_mask)
+{
+   struct drm_device *dev = state->dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
+   

[Intel-gfx] [PATCH v11 5/7] drm/i915/skl: Ensure pipes with changed wms get added to the state

[Lyude]

If we're enabling a pipe, we'll need to modify the watermarks on all
active planes. Since those planes won't be added to the state on
their own, we need to add them ourselves.

Signed-off-by: Lyude 
Reviewed-by: Matt Roper 
Cc: sta...@vger.kernel.org
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Radhakrishna Sripada 
Cc: Hans de Goede 
---
 drivers/gpu/drm/i915/intel_pm.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index e8653d8..f2e0071 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4058,6 +4058,10 @@ skl_compute_ddb(struct drm_atomic_state *state)
ret = skl_allocate_pipe_ddb(cstate, ddb);
if (ret)
return ret;
+
+   ret = drm_atomic_add_affected_planes(state, _crtc->base);
+   if (ret)
+   return ret;
}
 
return 0;
-- 
2.7.4

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

[Intel-gfx] [PATCH v11 4/7] drm/i915/skl: Update plane watermarks atomically during plane updates

[Lyude]

Thanks to Ville for suggesting this as a potential solution to pipe
underruns on Skylake.

On Skylake all of the registers for configuring planes, including the
registers for configuring their watermarks, are double buffered. New
values written to them won't take effect until said registers are
"armed", which is done by writing to the PLANE_SURF (or in the case of
cursor planes, the CURBASE register) register.

With this in mind, up until now we've been updating watermarks on skl
like this:

  non-modeset {
   - calculate (during atomic check phase)
   - finish_atomic_commit:
 - intel_pre_plane_update:
- intel_update_watermarks()
 - {vblank happens; new watermarks + old plane values => underrun }
 - drm_atomic_helper_commit_planes_on_crtc:
- start vblank evasion
- write new plane registers
- end vblank evasion
  }

  or

  modeset {
   - calculate (during atomic check phase)
   - finish_atomic_commit:
 - crtc_enable:
- intel_update_watermarks()
 - {vblank happens; new watermarks + old plane values => underrun }
 - drm_atomic_helper_commit_planes_on_crtc:
- start vblank evasion
- write new plane registers
- end vblank evasion
  }

Now we update watermarks atomically like this:

  non-modeset {
   - calculate (during atomic check phase)
   - finish_atomic_commit:
 - intel_pre_plane_update:
- intel_update_watermarks() (wm values aren't written yet)
 - drm_atomic_helper_commit_planes_on_crtc:
- start vblank evasion
- write new plane registers
- write new wm values
- end vblank evasion
  }

  modeset {
   - calculate (during atomic check phase)
   - finish_atomic_commit:
 - crtc_enable:
- intel_update_watermarks() (actual wm values aren't written
  yet)
 - drm_atomic_helper_commit_planes_on_crtc:
- start vblank evasion
- write new plane registers
- write new wm values
- end vblank evasion
  }

So this patch moves all of the watermark writes into the right place;
inside of the vblank evasion where we update all of the registers for
each plane. While this patch doesn't fix everything, it does allow us to
update the watermark values in the way the hardware expects us to.

Changes since original patch series:
 - Remove mutex_lock/mutex_unlock since they don't do anything and we're
   not touching global state
 - Move skl_write_cursor_wm/skl_write_plane_wm functions into
   intel_pm.c, make externally visible
 - Add skl_write_plane_wm calls to skl_update_plane
 - Fix conditional for for loop in skl_write_plane_wm (level < max_level
   should be level <= max_level)
 - Make diagram in commit more accurate to what's actually happening
 - Add Fixes:

Changes since v1:
 - Use IS_GEN9() instead of IS_SKYLAKE() since these fixes apply to more
   then just Skylake
 - Update description to make it clear this patch doesn't fix everything
 - Check if pipes were actually changed before writing watermarks

Changes since v2:
 - Write PIPE_WM_LINETIME during vblank evasion

Changes since v3:
 - Rebase against new SAGV patch changes

Changes since v4:
 - Add a parameter to choose what skl_wm_values struct to use when
   writing new plane watermarks

Changes since v5:
 - Remove cursor ddb entry write in skl_write_cursor_wm(), defer until
   patch 6
 - Write WM_LINETIME in intel_begin_crtc_commit()

Changes since v6:
 - Remove redundant dirty_pipes check in skl_write_plane_wm (we check
   this in all places where we call this function, and it was supposed
   to have been removed earlier anyway)
 - In i9xx_update_cursor(), use dev_priv->info.gen >= 9 instead of
   IS_GEN9(dev_priv). We do this everywhere else and I'd imagine this
   needs to be done for gen10 as well

Fixes: 2d41c0b59afc ("drm/i915/skl: SKL Watermark Computation")
Signed-off-by: Lyude 
Reviewed-by: Matt Roper 
Cc: sta...@vger.kernel.org
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Radhakrishna Sripada 
Cc: Hans de Goede 
---
 drivers/gpu/drm/i915/intel_display.c | 17 +++-
 drivers/gpu/drm/i915/intel_drv.h |  5 
 drivers/gpu/drm/i915/intel_pm.c  | 50 
 drivers/gpu/drm/i915/intel_sprite.c  |  7 +
 4 files changed, 62 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 35bdd67..b2f8e24 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3386,6 +3386,8 @@ static void skylake_update_primary_plane(struct drm_plane 
*plane,
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->base.crtc);
struct drm_framebuffer *fb = plane_state->base.fb;
+   struct drm_i915_gem_object *obj = 

[Intel-gfx] [PATCH v11 0/7] Finally fix watermarks

[Lyude]

Maarten Lankhorst unfortunately found that some early pre-release skl machines
were failing tests due to them apparently not having SAGVs. As a result, a
patch had to be added to check for invalid pcode commands, and the SAGV support
patch has been reworked to stop trying to play with the SAGV if it's not
controllable on the system. As well, this means the RBs for:

drm/i915/skl: Add support for the SAGV, fix underrun hangs

Had to be cleared, seeing as the patch has changed considerably now.

Lyude (6):
  drm/i915/gen6+: Return -EINVAL on invalid pcode commands
  drm/i915/skl: Add support for the SAGV, fix underrun hangs
  drm/i915/skl: Update plane watermarks atomically during plane updates
  drm/i915/skl: Ensure pipes with changed wms get added to the state
  drm/i915: Move CRTC updating in atomic_commit into it's own hook
  drm/i915/skl: Update DDB values atomically with wms/plane attrs

Matt Roper (1):
  drm/i915/gen9: Only copy WM results for changed pipes to skl_hw

 drivers/gpu/drm/i915/i915_drv.h  |   9 +
 drivers/gpu/drm/i915/i915_reg.h  |   5 +
 drivers/gpu/drm/i915/intel_display.c | 198 +++
 drivers/gpu/drm/i915/intel_drv.h |  14 ++
 drivers/gpu/drm/i915/intel_pm.c  | 356 +++
 drivers/gpu/drm/i915/intel_sprite.c  |   6 +
 6 files changed, 395 insertions(+), 193 deletions(-)

-- 
2.7.4

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

[Intel-gfx] [PATCH v11 6/7] drm/i915: Move CRTC updating in atomic_commit into it's own hook

[Lyude]

Since we have to write ddb allocations at the same time as we do other
plane updates, we're going to need to be able to control the order in
which we execute modesets on each pipe. The easiest way to do this is to
just factor this section of intel_atomic_commit_tail()
(intel_atomic_commit() for stable branches) into it's own function, and
add an appropriate display function hook for it.

Based off of Matt Rope's suggestions

Changes since v1:
 - Drop pipe_config->base.active check in intel_update_crtcs() since we
   check that before calling the function

Signed-off-by: Lyude 
Reviewed-by: Matt Roper 
[omitting CC for stable, since this patch will need to be changed for
such backports first]
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Radhakrishna Sripada 
Cc: Hans de Goede 

Signed-off-by: Lyude 
---
 drivers/gpu/drm/i915/i915_drv.h  |  2 +
 drivers/gpu/drm/i915/intel_display.c | 74 +---
 2 files changed, 54 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d74d166..61f2534 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -630,6 +630,8 @@ struct drm_i915_display_funcs {
  struct intel_crtc_state *crtc_state);
void (*crtc_enable)(struct drm_crtc *crtc);
void (*crtc_disable)(struct drm_crtc *crtc);
+   void (*update_crtcs)(struct drm_atomic_state *state,
+unsigned int *crtc_vblank_mask);
void (*audio_codec_enable)(struct drm_connector *connector,
   struct intel_encoder *encoder,
   const struct drm_display_mode 
*adjusted_mode);
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index b2f8e24..61a45f1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14063,6 +14063,52 @@ static bool needs_vblank_wait(struct intel_crtc_state 
*crtc_state)
return false;
 }
 
+static void intel_update_crtc(struct drm_crtc *crtc,
+ struct drm_atomic_state *state,
+ struct drm_crtc_state *old_crtc_state,
+ unsigned int *crtc_vblank_mask)
+{
+   struct drm_device *dev = crtc->dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   struct intel_crtc_state *pipe_config = to_intel_crtc_state(crtc->state);
+   bool modeset = needs_modeset(crtc->state);
+
+   if (modeset) {
+   update_scanline_offset(intel_crtc);
+   dev_priv->display.crtc_enable(crtc);
+   } else {
+   intel_pre_plane_update(to_intel_crtc_state(old_crtc_state));
+   }
+
+   if (drm_atomic_get_existing_plane_state(state, crtc->primary)) {
+   intel_fbc_enable(
+   intel_crtc, pipe_config,
+   to_intel_plane_state(crtc->primary->state));
+   }
+
+   drm_atomic_helper_commit_planes_on_crtc(old_crtc_state);
+
+   if (needs_vblank_wait(pipe_config))
+   *crtc_vblank_mask |= drm_crtc_mask(crtc);
+}
+
+static void intel_update_crtcs(struct drm_atomic_state *state,
+  unsigned int *crtc_vblank_mask)
+{
+   struct drm_crtc *crtc;
+   struct drm_crtc_state *old_crtc_state;
+   int i;
+
+   for_each_crtc_in_state(state, crtc, old_crtc_state, i) {
+   if (!crtc->state->active)
+   continue;
+
+   intel_update_crtc(crtc, state, old_crtc_state,
+ crtc_vblank_mask);
+   }
+}
+
 static void intel_atomic_commit_tail(struct drm_atomic_state *state)
 {
struct drm_device *dev = state->dev;
@@ -14162,17 +14208,9 @@ static void intel_atomic_commit_tail(struct 
drm_atomic_state *state)
intel_modeset_verify_disabled(dev);
}
 
-   /* Now enable the clocks, plane, pipe, and connectors that we set up. */
+   /* Complete the events for pipes that have now been disabled */
for_each_crtc_in_state(state, crtc, old_crtc_state, i) {
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
bool modeset = needs_modeset(crtc->state);
-   struct intel_crtc_state *pipe_config =
-   to_intel_crtc_state(crtc->state);
-
-   if (modeset && crtc->state->active) {
-   update_scanline_offset(to_intel_crtc(crtc));
-   dev_priv->display.crtc_enable(crtc);
-   }
 
/* Complete events for now disable pipes here. */
if (modeset && !crtc->state->active && 

[Intel-gfx] [PATCH v11 1/7] drm/i915/gen6+: Return -EINVAL on invalid pcode commands

[Lyude]

In order to add proper support for the SAGV, we need to be able to know
what the cause of a failure to change the SAGV through the pcode mailbox
was. The reasoning for this is that some very early pre-release Skylake
machines don't actually allow you to control the SAGV on them, and
indicate an invalid mailbox command was sent.

This also might come in handy in the future for debugging.

Signed-off-by: Lyude 
Cc: Matt Roper 
Cc: Maarten Lankhorst 
Cc: Daniel Vetter 
Cc: Ville Syrjälä 
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/i915/i915_reg.h |  1 +
 drivers/gpu/drm/i915/intel_pm.c | 10 ++
 2 files changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index da82744..73b3d4d 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7121,6 +7121,7 @@ enum {
 #define VLV_MEDIA_C0_COUNT _MMIO(0x13811C)
 
 #define GEN6_PCODE_MAILBOX _MMIO(0x138124)
+#define   GEN6_PCODE_INVALID_CMD   (1<<0)
 #define   GEN6_PCODE_READY (1<<31)
 #define  GEN6_PCODE_WRITE_RC6VIDS  0x4
 #define  GEN6_PCODE_READ_RC6VIDS   0x5
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 99014d7..8752730 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -7674,6 +7674,11 @@ int sandybridge_pcode_read(struct drm_i915_private 
*dev_priv, u32 mbox, u32 *val
*val = I915_READ_FW(GEN6_PCODE_DATA);
I915_WRITE_FW(GEN6_PCODE_DATA, 0);
 
+   if (I915_READ_FW(GEN6_PCODE_MAILBOX) & GEN6_PCODE_INVALID_CMD) {
+   DRM_DEBUG_DRIVER("warning: pcode (read) mailbox access 
indicated invalid command\n");
+   return -EINVAL;
+   }
+
return 0;
 }
 
@@ -7704,6 +7709,11 @@ int sandybridge_pcode_write(struct drm_i915_private 
*dev_priv,
 
I915_WRITE_FW(GEN6_PCODE_DATA, 0);
 
+   if (I915_READ_FW(GEN6_PCODE_MAILBOX) & GEN6_PCODE_INVALID_CMD) {
+   DRM_DEBUG_DRIVER("warning: pcode (write) mailbox access 
indicated invalid command\n");
+   return -EINVAL;
+   }
+
return 0;
 }
 
-- 
2.7.4

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

[Intel-gfx] [PATCH v11 3/7] drm/i915/gen9: Only copy WM results for changed pipes to skl_hw

[Lyude]

From: Matt Roper 

When we write watermark values to the hardware, those values are stored
in dev_priv->wm.skl_hw.  However with recent watermark changes, the
results structure we're copying from only contains valid watermark and
DDB values for the pipes that are actually changing; the values for
other pipes remain 0.  Thus a blind copy of the entire skl_wm_values
structure will clobber the values for unchanged pipes...we need to be
more selective and only copy over the values for the changing pipes.

This mistake was hidden until recently due to another bug that caused us
to erroneously re-calculate watermarks for all active pipes rather than
changing pipes.  Only when that bug was fixed was the impact of this bug
discovered (e.g., modesets failing with "Requested display configuration
exceeds system watermark limitations" messages and leaving watermarks
non-functional, even ones initiated by intel_fbdev_restore_mode).

Changes since v1:
 - Add a function for copying a pipe's wm values
   (skl_copy_wm_for_pipe()) so we can reuse this later

Fixes: 734fa01f3a17 ("drm/i915/gen9: Calculate watermarks during atomic 'check' 
(v2)")
Fixes: 9b6130227495 ("drm/i915/gen9: Re-allocate DDB only for changed pipes")
Signed-off-by: Matt Roper 
Signed-off-by: Lyude 
Reviewed-by: Matt Roper 
Cc: sta...@vger.kernel.org
Cc: Maarten Lankhorst 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Radhakrishna Sripada 
Cc: Hans de Goede 
---
 drivers/gpu/drm/i915/intel_pm.c | 28 ++--
 1 file changed, 26 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 0a202264..77166c6 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4045,6 +4045,24 @@ skl_compute_ddb(struct drm_atomic_state *state)
return 0;
 }
 
+static void
+skl_copy_wm_for_pipe(struct skl_wm_values *dst,
+struct skl_wm_values *src,
+enum pipe pipe)
+{
+   dst->wm_linetime[pipe] = src->wm_linetime[pipe];
+   memcpy(dst->plane[pipe], src->plane[pipe],
+  sizeof(dst->plane[pipe]));
+   memcpy(dst->plane_trans[pipe], src->plane_trans[pipe],
+  sizeof(dst->plane_trans[pipe]));
+
+   dst->ddb.pipe[pipe] = src->ddb.pipe[pipe];
+   memcpy(dst->ddb.y_plane[pipe], src->ddb.y_plane[pipe],
+  sizeof(dst->ddb.y_plane[pipe]));
+   memcpy(dst->ddb.plane[pipe], src->ddb.plane[pipe],
+  sizeof(dst->ddb.plane[pipe]));
+}
+
 static int
 skl_compute_wm(struct drm_atomic_state *state)
 {
@@ -4117,8 +4135,10 @@ static void skl_update_wm(struct drm_crtc *crtc)
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
struct skl_wm_values *results = _priv->wm.skl_results;
+   struct skl_wm_values *hw_vals = _priv->wm.skl_hw;
struct intel_crtc_state *cstate = to_intel_crtc_state(crtc->state);
struct skl_pipe_wm *pipe_wm = >wm.skl.optimal;
+   int pipe;
 
if ((results->dirty_pipes & drm_crtc_mask(crtc)) == 0)
return;
@@ -4130,8 +4150,12 @@ static void skl_update_wm(struct drm_crtc *crtc)
skl_write_wm_values(dev_priv, results);
skl_flush_wm_values(dev_priv, results);
 
-   /* store the new configuration */
-   dev_priv->wm.skl_hw = *results;
+   /*
+* Store the new configuration (but only for the pipes that have
+* changed; the other values weren't recomputed).
+*/
+   for_each_pipe_masked(dev_priv, pipe, results->dirty_pipes)
+   skl_copy_wm_for_pipe(hw_vals, results, pipe);
 
mutex_unlock(_priv->wm.wm_mutex);
 }
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH 2/3] drm/dp/i915: Clean up clock configuration for HDMI audio

[Pandiyan, Dhinakaran]

On Thu, 2016-08-11 at 10:52 +0300, Jani Nikula wrote:
> On Thu, 11 Aug 2016, Dhinakaran Pandiyan  
> wrote:
> > No functional change, just clean up. Debug messages now print out clock
> > units. Additionally, the configuration bits, which are 1:1 mapped to the
> > clock frequency and don't convey much information are not printed out.
> 
> IMO the cleanups here are subjective, i.e. another day someone might
> come in and rewrite it back to having just one code path for return
> instead of many. And someone might prefer early returns for errors.

Fair enough. The change in return style is subjective, I will drop this
patch. Thanks for pointing it out.

> If you really wanted to clean this up, you could abstract the config
> lookup based on clock, and it would be a less subjective improvement.
> 
I guess, this would involve an additional data structure. I will leave
it as it is.

> >
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/intel_audio.c | 20 
> >  1 file changed, 8 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> > b/drivers/gpu/drm/i915/intel_audio.c
> > index 3efce0e..9465f54 100644
> > --- a/drivers/gpu/drm/i915/intel_audio.c
> > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > @@ -104,21 +104,17 @@ static u32 audio_config_hdmi_pixel_clock(const struct 
> > drm_display_mode *adjusted
> > int i;
> >  
> > for (i = 0; i < ARRAY_SIZE(hdmi_audio_clock); i++) {
> > -   if (adjusted_mode->crtc_clock == hdmi_audio_clock[i].clock)
> > -   break;
> > -   }
> > -
> > -   if (i == ARRAY_SIZE(hdmi_audio_clock)) {
> > -   DRM_DEBUG_KMS("HDMI audio pixel clock setting for %d not found, 
> > falling back to defaults\n",
> > - adjusted_mode->crtc_clock);
> > -   i = 1;
> > +   if (adjusted_mode->crtc_clock == hdmi_audio_clock[i].clock) {
> > +   DRM_DEBUG_KMS("Configuring audio for HDMI pixel clk 
> > %dkHz\n",
> > + hdmi_audio_clock[i].clock);
> > +   return hdmi_audio_clock[i].config;
> > +   }
> > }
> >  
> > -   DRM_DEBUG_KMS("Configuring HDMI audio for pixel clock %d (0x%08x)\n",
> > - hdmi_audio_clock[i].clock,
> > - hdmi_audio_clock[i].config);
> > +   DRM_DEBUG_KMS("No config. for HDMI pixel clk %dkHz, using default 
> > %dkHz\n",
> 
> Please at least fix the typos.
> 
Probably the abbreviation was not obvious. I guess, the clock frequency
units are standard in i915 too. Thanks for you time.

> > + adjusted_mode->crtc_clock, hdmi_audio_clock[1].clock);
> >  
> > -   return hdmi_audio_clock[i].config;
> > +   return hdmi_audio_clock[1].config;
> >  }
> >  
> >  static int audio_config_get_n(const struct drm_display_mode *mode, int 
> > rate)
> 

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

Re: [Intel-gfx] [PATCH v4 6/6] drm/i915/huc: Add BXT HuC Loading Support

[Antoine, Peter]

The number of dull conversations I have had about the format of the uC firmware 
names are legion.
I will be glad to never have another. It is now someones elses problem.

Thanks for the review.

Peter.

-Original Message-
From: Gordon, David S 
Sent: Thursday, August 11, 2016 5:31 PM
To: Antoine, Peter ; intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v4 6/6] drm/i915/huc: Add BXT HuC Loading Support

On 04/08/16 09:16, Peter Antoine wrote:
> This patch adds the HuC Loading for the BXT.
> Version 1.7 of the HuC firmware.
>
> v2: rebased.
> v3: rebased.
> changed file name to match the install package format.
> v4: rebased.
>
> Signed-off-by: Peter Antoine 
> ---
>  drivers/gpu/drm/i915/intel_huc_loader.c | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_huc_loader.c 
> b/drivers/gpu/drm/i915/intel_huc_loader.c
> index 21393ad..3588a95 100644
> --- a/drivers/gpu/drm/i915/intel_huc_loader.c
> +++ b/drivers/gpu/drm/i915/intel_huc_loader.c
> @@ -49,6 +49,9 @@
>  #define I915_SKL_HUC_UCODE "i915/skl_huc_ver01_07_1398.bin"
>  MODULE_FIRMWARE(I915_SKL_HUC_UCODE);
>
> +#define I915_BXT_HUC_UCODE "i915/bxt_huc_ver01_07_1398.bin"
> +MODULE_FIRMWARE(I915_BXT_HUC_UCODE);

We don't really want to use this format for the firmware name.
But we'll fix that in the next version, when the naming gets unified across all 
the uC devices :) So

Reviewed-by: Dave Gordon 

>  /**
>   * intel_huc_load_ucode() - DMA's the firmware
>   * @dev: the drm device
> @@ -157,6 +160,10 @@ void intel_huc_init(struct drm_device *dev)
>   fw_path = I915_SKL_HUC_UCODE;
>   huc_fw->major_ver_wanted = 1;
>   huc_fw->minor_ver_wanted = 7;
> + } else if (IS_BROXTON(dev_priv)) {
> + fw_path = I915_BXT_HUC_UCODE;
> + huc_fw->major_ver_wanted = 1;
> + huc_fw->minor_ver_wanted = 7;
>   }
>
>   if (fw_path == NULL)
>

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

[Intel-gfx] linux-firmware-i915 pull request (restore skl dmc 1.23)

[Vivi, Rodrigo]

The following changes since commit
c170c8d95794d6aedbaeea44674daaa96baf04f7:

  linux-firmware: intel: Update Skylake audio firmware (2016-08-04
16:09:21 +0530)

are available in the git repository at:

  git://people.freedesktop.org/~vivijim/linux-firmware-i915 master

for you to fetch changes up to
3d1020bb4006e21c4eeca368044f16c9c206394e:

  linux-firmware/i915: Restore DMC 1.23 (2016-08-11 11:16:09 -0700)


Rodrigo Vivi (1):
  linux-firmware/i915: Restore DMC 1.23

 WHENCE   |   1 +
 i915/skl_dmc_ver1_23.bin | Bin 0 -> 8824 bytes
 2 files changed, 1 insertion(+)
 create mode 100644 i915/skl_dmc_ver1_23.bin
___
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: Eliminate redundant local variable definition

[Pandiyan, Dhinakaran]

On Thu, 2016-08-11 at 08:09 +0100, Chris Wilson wrote:
> On Wed, Aug 10, 2016 at 11:41:13PM -0700, Dhinakaran Pandiyan wrote:
> > No functional change, just clean up.
> > 
> > Signed-off-by: Dhinakaran Pandiyan 
> Reviewed-by: Chris Wilson 
> 
> A quick conversion to kernel types would also be appreciated.
> -Chris
> 
Thanks for the review.

Just so that I don't misunderstand, do you mean this?
 /s/uint32_t/u32  
 /s/uint8_t/u8 


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

Re: [Intel-gfx] [PATCH v7 1/5] drm: Read DP branch device HW revision

[Ville Syrjälä]

On Thu, Aug 11, 2016 at 10:21:36AM -0700, Jim Bride wrote:
> On Thu, Aug 11, 2016 at 11:22:15AM +0300, Ville Syrjälä wrote:
> > On Thu, Aug 11, 2016 at 11:14:43AM +0300, Mika Kahola wrote:
> > > On Thu, 2016-08-11 at 10:10 +0300, Ville Syrjälä wrote:
> > > > On Mon, Aug 08, 2016 at 04:00:26PM +0300, Mika Kahola wrote:
> > > > > HW revision is mandatory field for DisplayPort branch
> > > > > devices. This is defined in DPCD register field 0x509.
> > > > 
> > > > But what do we want to do with it? Me, I don't see a point in parsing a
> > > > bunch of stuff from the DPCD unless there's a real use case for it.
> > > > /dev/drm_dp_aux will provide all the debug aid we need if we need to
> > > > check random pieces of data from the DPCD, so even exposing this sort
> > > > of stuff via debugfs is IMO pretty pointless.
> > > > 
> > > > If there's a good reason for a debug print, then I think we could parse
> > > > something and dump it out so that it's always in the dmesg. But so far
> > > > I'm not aware of any bug that would have required to deal with different
> > > > hw revisions of things and whatnot.
> > > > 
> > > Digging up the HW and SW revisions are just for debugging purposes. My
> > > idea here was that it would be handy if this information would be
> > > available if we face a problem let's say with VGA dongle for example. It
> > > is true that at the moment we don't have a single bug that would require
> > > HW/SW revision information but maybe in the future we have one.
> > > 
> > > So, if we don't want to have this stuff in drm_dp_helpers and/or debugfs
> > > I could make a change and print this info on dmesg when DP branch device
> > > is plugged in.
> > 
> > Perhaps. We do print out the OUI as well, so there is some precedent.
> 
> Even if we don't dump stuff out to dmesg, I'd like to see this information
> in the mst_info debugfs file or someplace similar.  As has been pointed out,
> having this information available in the event that we need to work with a
> vendor on a problem would be a help.

Just dump the whole thing via /dev/drm_dp_aux. The problem with
getting parsed data for debugging is that the parser itself might be
buggy or just incomplete. So IMO it's always much better to get the
raw data. This way you can be sure that it's not affected by the parser,
and that you get all of the data and don't have to back asking for more all
the time.

I really hate it when someone attaches a parsed VBT dump to a bug for
instance. It's pretty much useless.

I've been waiting for someone to step up and write a userspace tool for
pretty printing the entire DPCD dumps. So far no one has volunteered.

> Jim
> 
> 
> > 
> > > 
> > > Cheers,
> > > Mika
> > > 
> > > > > 
> > > > > v2: move drm_dp_ds_revision structure to be part of
> > > > > drm_dp_link structure (Daniel)
> > > > > 
> > > > > Signed-off-by: Mika Kahola 
> > > > > ---
> > > > >  drivers/gpu/drm/drm_dp_helper.c  | 27 +++
> > > > >  drivers/gpu/drm/i915/intel_drv.h |  1 +
> > > > >  include/drm/drm_dp_helper.h  |  9 +
> > > > >  3 files changed, 37 insertions(+)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/drm_dp_helper.c 
> > > > > b/drivers/gpu/drm/drm_dp_helper.c
> > > > > index 75b2873..5fecdc1 100644
> > > > > --- a/drivers/gpu/drm/drm_dp_helper.c
> > > > > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > > > > @@ -514,6 +514,33 @@ int drm_dp_downstream_max_bpc(const u8 
> > > > > dpcd[DP_RECEIVER_CAP_SIZE],
> > > > >  EXPORT_SYMBOL(drm_dp_downstream_max_bpc);
> > > > >  
> > > > >  /**
> > > > > + * drm_dp_downstream_hw_rev() - read DP branch device HW revision
> > > > > + * @aux: DisplayPort AUX channel
> > > > > + *
> > > > > + * Returns 0 on succes or negative error code on failure
> > > > > + */
> > > > > +int drm_dp_downstream_hw_rev(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> > > > > +  struct drm_dp_aux *aux, struct drm_dp_link 
> > > > > *link)
> > > > > +{
> > > > > + uint8_t tmp;
> > > > > + int err;
> > > > > +
> > > > > + if (!(dpcd[DP_DOWNSTREAMPORT_PRESENT] & 
> > > > > DP_DWN_STRM_PORT_PRESENT))
> > > > > + return -EINVAL;
> > > > > +
> > > > > + err = drm_dp_dpcd_read(aux, DP_BRANCH_HW_REV, , 1);
> > > > > +
> > > > > + if (err < 0)
> > > > > + return err;
> > > > > +
> > > > > + link->ds_hw_rev.major = (tmp & 0xf0) >> 4;
> > > > > + link->ds_hw_rev.minor = tmp & 0xf;
> > > > > +
> > > > > + return 0;
> > > > > +}
> > > > > +EXPORT_SYMBOL(drm_dp_downstream_hw_rev);
> > > > > +
> > > > > +/**
> > > > >   * drm_dp_downstream_id() - identify branch device
> > > > >   * @aux: DisplayPort AUX channel
> > > > >   *
> > > > > diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> > > > > b/drivers/gpu/drm/i915/intel_drv.h
> > > > > index e74d851..a6eccf5 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > > > @@ -865,6 +865,7 @@ struct 

[Intel-gfx] ✗ Ro.CI.BAT: failure for Reclassify messages from GuC loader/submission (rev3)

[Patchwork]

== Series Details ==

Series: Reclassify messages from GuC loader/submission (rev3)
URL   : https://patchwork.freedesktop.org/series/10918/
State : failure

== Summary ==

Series 10918v3 Reclassify messages from GuC loader/submission
http://patchwork.freedesktop.org/api/1.0/series/10918/revisions/3/mbox

Test gem_exec_suspend:
Subgroup basic-s3:
dmesg-warn -> PASS   (ro-bdw-i7-5600u)
Test kms_cursor_legacy:
Subgroup basic-cursor-vs-flip-varying-size:
pass   -> FAIL   (ro-ilk1-i5-650)
Subgroup basic-flip-vs-cursor-legacy:
fail   -> PASS   (ro-bdw-i5-5250u)
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-b-frame-sequence:
fail   -> PASS   (ro-ivb2-i7-3770)
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> SKIP   (ro-bdw-i5-5250u)
Subgroup suspend-read-crc-pipe-b:
skip   -> DMESG-WARN (ro-bdw-i5-5250u)
Subgroup suspend-read-crc-pipe-c:
skip   -> DMESG-WARN (ro-bdw-i5-5250u)

ro-bdw-i5-5250u  total:240  pass:219  dwarn:3   dfail:0   fail:1   skip:17 
ro-bdw-i7-5557U  total:240  pass:220  dwarn:1   dfail:0   fail:0   skip:19 
ro-bdw-i7-5600u  total:240  pass:207  dwarn:0   dfail:0   fail:1   skip:32 
ro-bsw-n3050 total:240  pass:194  dwarn:0   dfail:0   fail:4   skip:42 
ro-byt-n2820 total:240  pass:197  dwarn:0   dfail:0   fail:3   skip:40 
ro-hsw-i3-4010u  total:240  pass:214  dwarn:0   dfail:0   fail:0   skip:26 
ro-hsw-i7-4770r  total:240  pass:185  dwarn:0   dfail:0   fail:0   skip:55 
ro-ilk1-i5-650   total:235  pass:173  dwarn:0   dfail:0   fail:2   skip:60 
ro-ivb-i7-3770   total:240  pass:205  dwarn:0   dfail:0   fail:0   skip:35 
ro-ivb2-i7-3770  total:240  pass:209  dwarn:0   dfail:0   fail:0   skip:31 
ro-skl3-i5-6260u total:240  pass:222  dwarn:0   dfail:0   fail:4   skip:14 

Results at /archive/results/CI_IGT_test/RO_Patchwork_1841/

4a26251 drm-intel-nightly: 2016y-08m-11d-16h-12m-42s UTC integration manifest
773b608 NOMERGE: next version of GuC firmware is 8.11
e3208ac drm/i915/guc: revisit GuC loader message levels
3dc113a drm/i915/guc: downgrade some DRM_ERROR() messages to DRM_WARN()
6cd71c4 drm: extra printk() wrapper macros

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

Re: [Intel-gfx] [PATCH v7 1/5] drm: Read DP branch device HW revision

[Jim Bride]

On Thu, Aug 11, 2016 at 11:22:15AM +0300, Ville Syrjälä wrote:
> On Thu, Aug 11, 2016 at 11:14:43AM +0300, Mika Kahola wrote:
> > On Thu, 2016-08-11 at 10:10 +0300, Ville Syrjälä wrote:
> > > On Mon, Aug 08, 2016 at 04:00:26PM +0300, Mika Kahola wrote:
> > > > HW revision is mandatory field for DisplayPort branch
> > > > devices. This is defined in DPCD register field 0x509.
> > > 
> > > But what do we want to do with it? Me, I don't see a point in parsing a
> > > bunch of stuff from the DPCD unless there's a real use case for it.
> > > /dev/drm_dp_aux will provide all the debug aid we need if we need to
> > > check random pieces of data from the DPCD, so even exposing this sort
> > > of stuff via debugfs is IMO pretty pointless.
> > > 
> > > If there's a good reason for a debug print, then I think we could parse
> > > something and dump it out so that it's always in the dmesg. But so far
> > > I'm not aware of any bug that would have required to deal with different
> > > hw revisions of things and whatnot.
> > > 
> > Digging up the HW and SW revisions are just for debugging purposes. My
> > idea here was that it would be handy if this information would be
> > available if we face a problem let's say with VGA dongle for example. It
> > is true that at the moment we don't have a single bug that would require
> > HW/SW revision information but maybe in the future we have one.
> > 
> > So, if we don't want to have this stuff in drm_dp_helpers and/or debugfs
> > I could make a change and print this info on dmesg when DP branch device
> > is plugged in.
> 
> Perhaps. We do print out the OUI as well, so there is some precedent.

Even if we don't dump stuff out to dmesg, I'd like to see this information
in the mst_info debugfs file or someplace similar.  As has been pointed out,
having this information available in the event that we need to work with a
vendor on a problem would be a help.

Jim


> 
> > 
> > Cheers,
> > Mika
> > 
> > > > 
> > > > v2: move drm_dp_ds_revision structure to be part of
> > > > drm_dp_link structure (Daniel)
> > > > 
> > > > Signed-off-by: Mika Kahola 
> > > > ---
> > > >  drivers/gpu/drm/drm_dp_helper.c  | 27 +++
> > > >  drivers/gpu/drm/i915/intel_drv.h |  1 +
> > > >  include/drm/drm_dp_helper.h  |  9 +
> > > >  3 files changed, 37 insertions(+)
> > > > 
> > > > diff --git a/drivers/gpu/drm/drm_dp_helper.c 
> > > > b/drivers/gpu/drm/drm_dp_helper.c
> > > > index 75b2873..5fecdc1 100644
> > > > --- a/drivers/gpu/drm/drm_dp_helper.c
> > > > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > > > @@ -514,6 +514,33 @@ int drm_dp_downstream_max_bpc(const u8 
> > > > dpcd[DP_RECEIVER_CAP_SIZE],
> > > >  EXPORT_SYMBOL(drm_dp_downstream_max_bpc);
> > > >  
> > > >  /**
> > > > + * drm_dp_downstream_hw_rev() - read DP branch device HW revision
> > > > + * @aux: DisplayPort AUX channel
> > > > + *
> > > > + * Returns 0 on succes or negative error code on failure
> > > > + */
> > > > +int drm_dp_downstream_hw_rev(const u8 dpcd[DP_RECEIVER_CAP_SIZE],
> > > > +struct drm_dp_aux *aux, struct drm_dp_link 
> > > > *link)
> > > > +{
> > > > +   uint8_t tmp;
> > > > +   int err;
> > > > +
> > > > +   if (!(dpcd[DP_DOWNSTREAMPORT_PRESENT] & 
> > > > DP_DWN_STRM_PORT_PRESENT))
> > > > +   return -EINVAL;
> > > > +
> > > > +   err = drm_dp_dpcd_read(aux, DP_BRANCH_HW_REV, , 1);
> > > > +
> > > > +   if (err < 0)
> > > > +   return err;
> > > > +
> > > > +   link->ds_hw_rev.major = (tmp & 0xf0) >> 4;
> > > > +   link->ds_hw_rev.minor = tmp & 0xf;
> > > > +
> > > > +   return 0;
> > > > +}
> > > > +EXPORT_SYMBOL(drm_dp_downstream_hw_rev);
> > > > +
> > > > +/**
> > > >   * drm_dp_downstream_id() - identify branch device
> > > >   * @aux: DisplayPort AUX channel
> > > >   *
> > > > diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> > > > b/drivers/gpu/drm/i915/intel_drv.h
> > > > index e74d851..a6eccf5 100644
> > > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > > @@ -865,6 +865,7 @@ struct intel_dp {
> > > > uint8_t num_sink_rates;
> > > > int sink_rates[DP_MAX_SUPPORTED_RATES];
> > > > struct drm_dp_aux aux;
> > > > +   struct drm_dp_link link;
> > > > uint8_t train_set[4];
> > > > int panel_power_up_delay;
> > > > int panel_power_down_delay;
> > > > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> > > > index 8e1fe58..1127948 100644
> > > > --- a/include/drm/drm_dp_helper.h
> > > > +++ b/include/drm/drm_dp_helper.h
> > > > @@ -446,6 +446,7 @@
> > > >  #define DP_SINK_OUI0x400
> > > >  #define DP_BRANCH_OUI  0x500
> > > >  #define DP_BRANCH_ID0x503
> > > > +#define DP_BRANCH_HW_REV0x509
> > > >  
> > > >  #define DP_SET_POWER0x600
> > > >  # 

[Intel-gfx] [PATCH v4 2/4] drm/i915/guc: downgrade some DRM_ERROR() messages to DRM_WARN()

[Dave Gordon]

Where we're going to continue regardless of the problem, rather than
fail, then the message should be a WARNing rather than an ERROR.

Signed-off-by: Dave Gordon 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 18 +++---
 1 file changed, 7 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 6831321..d43625f 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -114,10 +114,8 @@ static int host2guc_action(struct intel_guc *guc, u32 
*data, u32 len)
if (ret != -ETIMEDOUT)
ret = -EIO;
 
-   DRM_ERROR("GUC: host2guc action 0x%X failed. ret=%d "
-   "status=0x%08X response=0x%08X\n",
-   data[0], ret, status,
-   I915_READ(SOFT_SCRATCH(15)));
+   DRM_WARN("Action 0x%X failed; ret=%d status=0x%08X 
response=0x%08X\n",
+data[0], ret, status, I915_READ(SOFT_SCRATCH(15)));
 
dev_priv->guc.action_fail += 1;
dev_priv->guc.action_err = ret;
@@ -556,8 +554,8 @@ static int guc_ring_doorbell(struct i915_guc_client *gc)
if (db_ret.db_status == GUC_DOORBELL_DISABLED)
break;
 
-   DRM_ERROR("Cookie mismatch. Expected %d, returned %d\n",
- db_cmp.cookie, db_ret.cookie);
+   DRM_WARN("Cookie mismatch. Expected %d, found %d\n",
+db_cmp.cookie, db_ret.cookie);
 
/* update the cookie to newly read cookie from GuC */
db_cmp.cookie = db_ret.cookie;
@@ -745,8 +743,8 @@ static void guc_init_doorbell_hw(struct intel_guc *guc)
/* Restore to original value */
err = guc_update_doorbell_id(guc, client, db_id);
if (err)
-   DRM_ERROR("Failed to restore doorbell to %d, err %d\n",
-   db_id, err);
+   DRM_WARN("Failed to restore doorbell to %d, err %d\n",
+db_id, err);
 
/* Read back & verify all doorbell registers */
for (i = 0; i < GUC_MAX_DOORBELLS; ++i)
@@ -834,8 +832,6 @@ static void guc_init_doorbell_hw(struct intel_guc *guc)
return client;
 
 err:
-   DRM_ERROR("FAILED to create priority %u GuC client!\n", priority);
-
guc_client_free(dev_priv, client);
return NULL;
 }
@@ -1015,7 +1011,7 @@ int i915_guc_submission_enable(struct drm_i915_private 
*dev_priv)
  GUC_CTX_PRIORITY_KMD_NORMAL,
  dev_priv->kernel_context);
if (!client) {
-   DRM_ERROR("Failed to create execbuf guc_client\n");
+   DRM_ERROR("Failed to create normal GuC client!\n");
return -ENOMEM;
}
 
-- 
1.9.1

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

[Intel-gfx] [PATCH v4 1/4] drm: extra printk() wrapper macros

[Dave Gordon]

We had only DRM_INFO() and DRM_ERROR(), whereas the underlying printk()
provides several other useful intermediate levels such as NOTICE and
WARNING. So this patch fills out the set by providing both regular and
once-only macros for each of the levels INFO, NOTICE, and WARNING, using
a common underlying macro that does all the token-pasting.

DRM_ERROR is unchanged, as it's not just a printk wrapper.

v2:
Fix whitespace, missing ## (Eric Engestrom)

Signed-off-by: Dave Gordon 
Reviewed-by: Eric Engestrom 
Cc: dri-de...@lists.freedesktop.org
---
 include/drm/drmP.h | 26 --
 1 file changed, 20 insertions(+), 6 deletions(-)

diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index f8e87fd..734e4fb 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -163,6 +163,26 @@ void drm_err(const char *format, ...);
 /** \name Macros to make printk easier */
 /*@{*/
 
+#define _DRM_PRINTK(once, level, fmt, ...) \
+   do {\
+   printk##once(KERN_##level "[" DRM_NAME "] " fmt,\
+##__VA_ARGS__);\
+   } while (0)
+
+#define DRM_INFO(fmt, ...) \
+   _DRM_PRINTK(, INFO, fmt, ##__VA_ARGS__)
+#define DRM_NOTE(fmt, ...) \
+   _DRM_PRINTK(, NOTICE, fmt, ##__VA_ARGS__)
+#define DRM_WARN(fmt, ...) \
+   _DRM_PRINTK(, WARNING, fmt, ##__VA_ARGS__)
+
+#define DRM_INFO_ONCE(fmt, ...)
\
+   _DRM_PRINTK(_once, INFO, fmt, ##__VA_ARGS__)
+#define DRM_NOTE_ONCE(fmt, ...)
\
+   _DRM_PRINTK(_once, NOTICE, fmt, ##__VA_ARGS__)
+#define DRM_WARN_ONCE(fmt, ...)
\
+   _DRM_PRINTK(_once, WARNING, fmt, ##__VA_ARGS__)
+
 /**
  * Error output.
  *
@@ -188,12 +208,6 @@ void drm_err(const char *format, ...);
drm_err(fmt, ##__VA_ARGS__);\
 })
 
-#define DRM_INFO(fmt, ...) \
-   printk(KERN_INFO "[" DRM_NAME "] " fmt, ##__VA_ARGS__)
-
-#define DRM_INFO_ONCE(fmt, ...)\
-   printk_once(KERN_INFO "[" DRM_NAME "] " fmt, ##__VA_ARGS__)
-
 /**
  * Debug output.
  *
-- 
1.9.1

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

[Intel-gfx] [PATCH v4 3/4] drm/i915/guc: revisit GuC loader message levels

[Dave Gordon]

Some downgraded from DRM_ERROR() to DRM_WARN() or DRM_NOTE(),
a few upgraded from DRM_INFO() to DRM_NOTE() or DRM_WARN(),
and one eliminated completely.

v2: different permutation of levels :)
v3: convert a couple of "this shouldn't happen" messages to WARN()

Signed-off-by: Dave Gordon 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_guc_loader.c | 34 -
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index bfcf6b5..c7b25f3 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -152,12 +152,14 @@ static u32 get_gttype(struct drm_i915_private *dev_priv)
 
 static u32 get_core_family(struct drm_i915_private *dev_priv)
 {
-   switch (INTEL_INFO(dev_priv)->gen) {
+   u32 gen = INTEL_GEN(dev_priv);
+
+   switch (gen) {
case 9:
return GFXCORE_FAMILY_GEN9;
 
default:
-   DRM_ERROR("GUC: unsupported core family\n");
+   WARN(1, "GEN%d does not support GuC operation!\n", gen);
return GFXCORE_FAMILY_UNKNOWN;
}
 }
@@ -447,7 +449,7 @@ int intel_guc_setup(struct drm_device *dev)
goto fail;
} else if (*fw_path == '\0') {
/* Device has a GuC but we don't know what f/w to load? */
-   DRM_INFO("No GuC firmware known for this platform\n");
+   WARN(1, "No GuC firmware known for this platform!\n");
err = -ENODEV;
goto fail;
}
@@ -485,10 +487,8 @@ int intel_guc_setup(struct drm_device *dev)
 * that the state and timing are fairly predictable
 */
err = i915_reset_guc(dev_priv);
-   if (err) {
-   DRM_ERROR("GuC reset failed: %d\n", err);
+   if (err)
goto fail;
-   }
 
err = guc_ucode_xfer(dev_priv);
if (!err)
@@ -546,15 +546,15 @@ int intel_guc_setup(struct drm_device *dev)
else if (err == 0)
DRM_INFO("GuC firmware load skipped\n");
else if (ret != -EIO)
-   DRM_INFO("GuC firmware load failed: %d\n", err);
+   DRM_NOTE("GuC firmware load failed: %d\n", err);
else
-   DRM_ERROR("GuC firmware load failed: %d\n", err);
+   DRM_WARN("GuC firmware load failed: %d\n", err);
 
if (i915.enable_guc_submission) {
if (fw_path == NULL)
DRM_INFO("GuC submission without firmware not 
supported\n");
if (ret == 0)
-   DRM_INFO("Falling back from GuC submission to execlist 
mode\n");
+   DRM_NOTE("Falling back from GuC submission to execlist 
mode\n");
else
DRM_ERROR("GuC init failed: %d\n", ret);
}
@@ -585,7 +585,7 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
intel_guc_fw *guc_fw)
 
/* Check the size of the blob before examining buffer contents */
if (fw->size < sizeof(struct guc_css_header)) {
-   DRM_ERROR("Firmware header is missing\n");
+   DRM_NOTE("Firmware header is missing\n");
goto fail;
}
 
@@ -597,7 +597,7 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
intel_guc_fw *guc_fw)
css->key_size_dw - css->exponent_size_dw) * sizeof(u32);
 
if (guc_fw->header_size != sizeof(struct guc_css_header)) {
-   DRM_ERROR("CSS header definition mismatch\n");
+   DRM_NOTE("CSS header definition mismatch\n");
goto fail;
}
 
@@ -607,7 +607,7 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
intel_guc_fw *guc_fw)
 
/* now RSA */
if (css->key_size_dw != UOS_RSA_SCRATCH_MAX_COUNT) {
-   DRM_ERROR("RSA key size is bad\n");
+   DRM_NOTE("RSA key size is bad\n");
goto fail;
}
guc_fw->rsa_offset = guc_fw->ucode_offset + guc_fw->ucode_size;
@@ -616,14 +616,14 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
intel_guc_fw *guc_fw)
/* At least, it should have header, uCode and RSA. Size of all three. */
size = guc_fw->header_size + guc_fw->ucode_size + guc_fw->rsa_size;
if (fw->size < size) {
-   DRM_ERROR("Missing firmware components\n");
+   DRM_NOTE("Missing firmware components\n");
goto fail;
}
 
/* Header and uCode will be loaded to WOPCM. Size of the two. */
size = guc_fw->header_size + guc_fw->ucode_size;
if (size > guc_wopcm_size(to_i915(dev))) {
-   DRM_ERROR("Firmware is too large to fit in WOPCM\n");
+   DRM_NOTE("Firmware is too large to fit in WOPCM\n");

[Intel-gfx] [PATCH v4 4/4] NOMERGE: next version of GuC firmware is 8.11

[Dave Gordon]

Update GuC firmware version to 8.11, and re-enable GuC loading and
submission by default on suitable platforms, since it's Intel's
Plan of Record that GuC submission shall be used where available.

Signed-off-by: Dave Gordon 
---
 drivers/gpu/drm/i915/i915_params.c  | 4 ++--
 drivers/gpu/drm/i915/intel_guc_loader.c | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 768ad89..02419a6 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -55,8 +55,8 @@ struct i915_params i915 __read_mostly = {
.verbose_state_checks = 1,
.nuclear_pageflip = 0,
.edp_vswing = 0,
-   .enable_guc_loading = 0,
-   .enable_guc_submission = 0,
+   .enable_guc_loading = -1,
+   .enable_guc_submission = -1,
.guc_log_level = -1,
.enable_dp_mst = true,
.inject_load_failure = 0,
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index c7b25f3..eb1b1e2 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -59,8 +59,8 @@
  *
  */
 
-#define SKL_FW_MAJOR 6
-#define SKL_FW_MINOR 1
+#define SKL_FW_MAJOR 8
+#define SKL_FW_MINOR 11
 
 #define BXT_FW_MAJOR 8
 #define BXT_FW_MINOR 7
-- 
1.9.1

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

[Intel-gfx] [PATCH v4 0/4] Reclassify messages from GuC loader/submission

[Dave Gordon]

Various downgrading, upgrading, or general reorganisation of the
messages emitted by the GuC code. As general principles:

* "can't happen" cases (inconsistencies/misconfiguration) are ERRORs
* recoverable (ignored) errors are downgraded to WARNINGs
* important auxiliary messages about failure or mode change are NOTICEs
* anything else (messages for developer rather than sysadmin) is DEBUG

v4:
  Resend with added cover letter 

Dave Gordon (4):
  drm: extra printk() wrapper macros
  drm/i915/guc: downgrade some DRM_ERROR() messages to DRM_WARN()
  drm/i915/guc: revisit GuC loader message levels
  drm/i915/guc: next version of GuC firmware is 8.11

 drivers/gpu/drm/i915/i915_guc_submission.c | 18 ++
 drivers/gpu/drm/i915/i915_params.c |  4 ++--
 drivers/gpu/drm/i915/intel_guc_loader.c| 38 +++---
 include/drm/drmP.h | 26 +++-
 4 files changed, 48 insertions(+), 38 deletions(-)

-- 
1.9.1

___
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/error: capture errored context based on request context-id

[Chris Wilson]

On Thu, Aug 11, 2016 at 05:09:01PM +0100, Arun Siluvery wrote:
> From: Dave Gordon 
> 
> Context capture hasn't worked for a while now, since the introduction of
> execlists because the function that records active context is using CCID
> register but this register contents are not valid in Execlist mode; this
> patch makes it work again by using a different way of identifying the
> context of interest in execlist mode.

Bzzt. The contexts are stored in the request and the iteration here is
still unsafe.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 15/33] drm/i915: Track pinned vma inside guc

[Chris Wilson]

On Thu, Aug 11, 2016 at 05:19:43PM +0100, Dave Gordon wrote:
> Summary: I'm not totally opposed to using VMAs more generally, but
> here there just seem to be extra costs with no offsetting
> advantages; and the details of some of the above changes are just
> plain ugly.

Shrug. Within i915_guc_submission you are primarily allocating GGTT space.
If you didn't mean to be, then address the code.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 3/6] drm/i915/huc: Add HuC fw loading support

[Dave Gordon]

On 04/08/16 09:16, Peter Antoine wrote:

The HuC loading process is similar to GuC. The intel_uc_fw_fetch()
is used for both cases.

HuC loading needs to be before GuC loading. The WOPCM setting must
be done early before loading any of them.

v2: rebased on-top of drm-intel-nightly.
removed if(HAS_GUC()) before the guc call. (D.Gordon)
update huc_version number of format.
v3: rebased to drm-intel-nightly, changed the file name format to
match the one in the huc package.
Changed dev->dev_provate to to_i915()
v4: moved function back to where it was.
change wait_for_automic to wait_for.

Signed-off-by: Alex Dai 
Signed-off-by: Peter Antoine 


This is going to need revisiting when Chris' conversion to 
VMAs-for-everything lands, but that's still in review (and could be for 
quite a while), so this is OK for today's version.


There are three minor points (numbered below) to be addressed, but once 
those are fixed, then:


Reviewed-by: Dave Gordon 

1: Several typos in the commit message above (e.g. 'dev_provate', 
'automic'),



---
 drivers/gpu/drm/i915/Makefile   |   1 +
 drivers/gpu/drm/i915/i915_drv.c |   3 +
 drivers/gpu/drm/i915/i915_drv.h |   3 +
 drivers/gpu/drm/i915/i915_guc_reg.h |   3 +
 drivers/gpu/drm/i915/intel_guc.h|   1 +
 drivers/gpu/drm/i915/intel_guc_loader.c |   6 +-
 drivers/gpu/drm/i915/intel_huc.h|  44 ++
 drivers/gpu/drm/i915/intel_huc_loader.c | 267 
 8 files changed, 326 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_huc.h
 create mode 100644 drivers/gpu/drm/i915/intel_huc_loader.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 6092f0e..f2794fd 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -49,6 +49,7 @@ i915-y += i915_cmd_parser.o \

 # general-purpose microcontroller (GuC) support
 i915-y += intel_guc_loader.o \
+ intel_huc_loader.o \
  i915_guc_submission.o

 # autogenerated null render state
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 83afdd0..41698ad 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -628,6 +628,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
 * working irqs for e.g. gmbus and dp aux transfers. */
intel_modeset_init(dev);

+   intel_huc_init(dev);
intel_guc_init(dev);

ret = i915_gem_init(dev);
@@ -653,6 +654,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
 cleanup_gem:
i915_gem_fini(dev);
 cleanup_irq:
+   intel_huc_fini(dev);
intel_guc_fini(dev);
drm_irq_uninstall(dev);
intel_teardown_gmbus(dev);
@@ -1327,6 +1329,7 @@ void i915_driver_unload(struct drm_device *dev)
/* Flush any outstanding unpin_work. */
drain_workqueue(dev_priv->wq);

+   intel_huc_fini(dev);
intel_guc_fini(dev);
i915_gem_fini(dev);
intel_fbc_cleanup_cfb(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 65ada5d..347e39c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -55,6 +55,7 @@
 #include "intel_bios.h"
 #include "intel_dpll_mgr.h"
 #include "intel_guc.h"
+#include "intel_huc.h"
 #include "intel_lrc.h"
 #include "intel_ringbuffer.h"

@@ -1743,6 +1744,7 @@ struct drm_i915_private {

struct intel_gvt gvt;

+   struct intel_huc huc;
struct intel_guc guc;

struct intel_csr csr;
@@ -2755,6 +2757,7 @@ struct drm_i915_cmd_table {
 #define HAS_GUC(dev)   (IS_GEN9(dev))
 #define HAS_GUC_UCODE(dev) (HAS_GUC(dev))
 #define HAS_GUC_SCHED(dev) (HAS_GUC(dev))
+#define HAS_HUC_UCODE(dev) (HAS_GUC(dev))

 #define HAS_RESOURCE_STREAMER(dev) (IS_HASWELL(dev) || \
INTEL_INFO(dev)->gen >= 8)
diff --git a/drivers/gpu/drm/i915/i915_guc_reg.h 
b/drivers/gpu/drm/i915/i915_guc_reg.h
index cf5a65b..51533f1 100644
--- a/drivers/gpu/drm/i915/i915_guc_reg.h
+++ b/drivers/gpu/drm/i915/i915_guc_reg.h
@@ -61,9 +61,12 @@
 #define   DMA_ADDRESS_SPACE_GTT  (8 << 16)
 #define DMA_COPY_SIZE  _MMIO(0xc310)
 #define DMA_CTRL   _MMIO(0xc314)
+#define   HUC_UKERNEL(1<<9)
 #define   UOS_MOVE   (1<<4)
 #define   START_DMA  (1<<0)
 #define DMA_GUC_WOPCM_OFFSET   _MMIO(0xc340)
+#define   HUC_LOADING_AGENT_VCR  (0<<1)
+#define   HUC_LOADING_AGENT_GUC  (1<<1)
 #define   GUC_WOPCM_OFFSET_VALUE 0x8   /* 512KB */
 #define GUC_MAX_IDLE_COUNT _MMIO(0xC3E4)

diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index ebf9c8d..c7b2745 100644
--- 

[Intel-gfx] ✗ Ro.CI.BAT: failure for capture error context

[Patchwork]

== Series Details ==

Series: capture error context
URL   : https://patchwork.freedesktop.org/series/10968/
State : failure

== Summary ==

Series 10968v1 capture error context
http://patchwork.freedesktop.org/api/1.0/series/10968/revisions/1/mbox

Test drv_module_reload_basic:
pass   -> SKIP   (ro-hsw-i3-4010u)
Test gem_exec_suspend:
Subgroup basic-s3:
incomplete -> DMESG-WARN (fi-skl-i7-6700k)
Test kms_cursor_legacy:
Subgroup basic-cursor-vs-flip-legacy:
pass   -> SKIP   (ro-hsw-i7-4770r)
Subgroup basic-cursor-vs-flip-varying-size:
pass   -> SKIP   (ro-hsw-i7-4770r)
Subgroup basic-flip-vs-cursor-legacy:
fail   -> SKIP   (ro-hsw-i7-4770r)
pass   -> FAIL   (ro-bdw-i5-5250u)
Subgroup basic-flip-vs-cursor-varying-size:
pass   -> SKIP   (ro-hsw-i7-4770r)
pass   -> FAIL   (ro-byt-n2820)
fail   -> PASS   (fi-hsw-i7-4770k)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass   -> SKIP   (ro-hsw-i7-4770r)
Subgroup basic-flip-vs-modeset:
pass   -> SKIP   (ro-hsw-i7-4770r)
Subgroup basic-flip-vs-wf_vblank:
pass   -> SKIP   (ro-hsw-i7-4770r)
Subgroup basic-plain-flip:
pass   -> SKIP   (ro-hsw-i7-4770r)
Test kms_frontbuffer_tracking:
Subgroup basic:
pass   -> SKIP   (ro-hsw-i7-4770r)
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-a:
pass   -> SKIP   (ro-hsw-i7-4770r)
Subgroup hang-read-crc-pipe-b:
pass   -> SKIP   (ro-hsw-i7-4770r)
Subgroup hang-read-crc-pipe-c:
pass   -> SKIP   (ro-hsw-i7-4770r)
Subgroup nonblocking-crc-pipe-a:
pass   -> SKIP   (ro-hsw-i7-4770r)
Subgroup nonblocking-crc-pipe-a-frame-sequence:
pass   -> SKIP   (ro-hsw-i7-4770r)
Subgroup nonblocking-crc-pipe-b:
pass   -> SKIP   (ro-hsw-i7-4770r)
Subgroup nonblocking-crc-pipe-b-frame-sequence:
pass   -> SKIP   (ro-hsw-i7-4770r)
Subgroup nonblocking-crc-pipe-c:
pass   -> SKIP   (ro-hsw-i7-4770r)
Subgroup nonblocking-crc-pipe-c-frame-sequence:
pass   -> SKIP   (ro-hsw-i7-4770r)
Subgroup read-crc-pipe-a:
pass   -> SKIP   (ro-hsw-i7-4770r)
Subgroup read-crc-pipe-a-frame-sequence:
pass   -> SKIP   (ro-hsw-i7-4770r)
Subgroup read-crc-pipe-b:
pass   -> SKIP   (ro-hsw-i7-4770r)
Subgroup read-crc-pipe-b-frame-sequence:
pass   -> SKIP   (ro-hsw-i7-4770r)
Subgroup read-crc-pipe-c:
pass   -> SKIP   (ro-hsw-i7-4770r)
Subgroup read-crc-pipe-c-frame-sequence:
pass   -> SKIP   (ro-hsw-i7-4770r)
Subgroup suspend-read-crc-pipe-a:
pass   -> SKIP   (ro-hsw-i7-4770r)
Subgroup suspend-read-crc-pipe-b:
pass   -> SKIP   (ro-hsw-i7-4770r)
dmesg-warn -> SKIP   (ro-bdw-i5-5250u)
Subgroup suspend-read-crc-pipe-c:
pass   -> SKIP   (ro-hsw-i7-4770r)
Test kms_psr_sink_crc:
Subgroup psr_basic:
skip   -> FAIL   (fi-hsw-i7-4770k)
Test pm_rpm:
Subgroup basic-pci-d3-state:
pass   -> SKIP   (ro-hsw-i7-4770r)
Subgroup basic-rte:
pass   -> SKIP   (ro-hsw-i7-4770r)

fi-hsw-i7-4770k  total:244  pass:222  dwarn:0   dfail:0   fail:1   skip:21 
fi-kbl-qkkr  total:244  pass:186  dwarn:30  dfail:0   fail:2   skip:26 
fi-skl-i5-6260u  total:244  pass:224  dwarn:4   dfail:0   fail:2   skip:14 
fi-skl-i7-6700k  total:244  pass:208  dwarn:4   dfail:2   fail:2   skip:28 
fi-snb-i7-2600   total:244  pass:202  dwarn:0   dfail:0   fail:0   skip:42 
ro-bdw-i5-5250u  total:240  pass:218  dwarn:3   dfail:0   fail:2   skip:17 
ro-bdw-i7-5600u  total:240  pass:207  dwarn:0   dfail:0   fail:1   skip:32 
ro-bsw-n3050 total:240  pass:194  dwarn:0   dfail:0   fail:4   skip:42 
ro-byt-n2820 total:240  pass:197  dwarn:0   dfail:0   fail:3   skip:40 
ro-hsw-i3-4010u  total:240  pass:213  dwarn:0   dfail:0   fail:0   skip:27 
ro-hsw-i7-4770r  total:240  pass:185  dwarn:0   dfail:0   fail:0   skip:55 
ro-ilk1-i5-650   total:235  pass:173  dwarn:0   dfail:0   fail:2   skip:60 
ro-ivb-i7-3770   total:240  pass:205  dwarn:0   dfail:0   fail:0   skip:35 
ro-ivb2-i7-3770  total:240  pass:209  dwarn:0   dfail:0   fail:0   skip:31 
ro-skl3-i5-6260u total:240  pass:222  dwarn:0   dfail:0   fail:4   skip:14 
ro-bdw-i7-5557U failed to 

Re: [Intel-gfx] [PATCH] drm/i915: Account for TSEG size when determining 865G stolen base

[Ville Syrjälä]

On Tue, Aug 09, 2016 at 09:53:47AM +0100, Chris Wilson wrote:
> On Mon, Aug 08, 2016 at 01:58:39PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > Looks like the TSEG lives just above TOUD, stolen comes after TSEG.
> > 
> > The spec seems somewhat self-contradictory in places, in the ESMRAMC
> > register desctription it says:
> >  TSEG Size:
> >   10=(TOUD + 512 KB) to TOUD
> >   11 =(TOUD + 1 MB) to TOUD
> > 
> > so that agrees with TSEG being at TOUD. But the example given
> > elsehwere in the spec says:
> > 
> >  TOUD equals 62.5 MB = 03E7h
> >  TSEG selected as 512 KB in size,
> >  Graphics local memory selected as 1 MB in size
> >  General System RAM available in system = 62.5 MB
> >  General system RAM rangeh to 03E7h
> >  TSEG address range03F8h to 03FFh
> >  TSEG pre-allocated from03F8h to 03FFh
> >  Graphics local memory pre-allocated from03E8h to 03F7h
> 
> Found that example:
> 
> """
> Notes on Pre-Allocated Memory for Graphics
> 
> These register bits control the use of memory from main memory space as
> graphics local memory.  The memory for TSEG is pre-allocated first and
> then the graphics local memory is pre-allocated. 
> """
>  
> > so here we have TSEG above stolen.
> > 
> > Real world evidence agrees with the TOUD->TSEG->stolen order however, so
> > let's fix up the code to account for the TSEG size.
> > 
> > Cc: Taketo Kabe 
> > Cc: Chris Wilson 
> > Cc: Daniel Vetter 
> > Cc: Thomas Gleixner 
> > Cc: Ingo Molnar 
> > Cc: "H. Peter Anvin" 
> > Cc: x...@kernel.org
> > Cc: sta...@vger.kernel.org
> > Fixes: 0ad98c74e093 ("drm/i915: Determine the stolen memory base address on 
> > gen2")
> > Fixes: a4dff76924fe ("x86/gpu: Add Intel graphics stolen memory quirk for 
> > gen2 platforms")
> > Reported-by: Taketo Kabe 
> > Tested-by: Taketo Kabe 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96473
> > Signed-off-by: Ville Syrjälä 
> 
> Link: http://download.intel.com/design/chipsets/datashts/25251405.pdf
> Reviewed-by: Chris Wilson 

Didn't see any objections from x86 folks, so I went and pushed this to
dinq. Thanks for the review.

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

Re: [Intel-gfx] [PATCH v2 12/12] drm/i915: Make sure fb offset is (macro)pixel aligned

[Ville Syrjälä]

On Wed, Aug 10, 2016 at 02:33:53PM +0300, Ville Syrjälä wrote:
> On Wed, Aug 10, 2016 at 02:02:43PM +0300, Ville Syrjälä wrote:
> > On Wed, Aug 10, 2016 at 12:04:32PM +0200, Daniel Vetter wrote:
> > > On Wed, Aug 10, 2016 at 12:23:21PM +0300, ville.syrj...@linux.intel.com 
> > > wrote:
> > > > From: Ville Syrjälä 
> > > > 
> > > > We convert the fb->offsets[] into x/y offsets, so they must be
> > > > (macro)pixel aligned. Check for this, and if things look good
> > > > allow fb->offsets[] != 0 when creating fbs since we now handle
> > > > them correctly.
> > > > 
> > > > v2: Move to last place in the series and improve the commit message
> > > > 
> > > > Signed-off-by: Ville Syrjälä 
> > > > Reviewed-by: Daniel Vetter  (v1)
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_display.c | 37 
> > > > +---
> > > >  1 file changed, 34 insertions(+), 3 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > > > b/drivers/gpu/drm/i915/intel_display.c
> > > > index f8487bcdb271..d3de56f0e764 100644
> > > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > > @@ -15370,6 +15370,37 @@ u32 intel_fb_pitch_limit(struct drm_device 
> > > > *dev, uint64_t fb_modifier,
> > > > }
> > > >  }
> > > >  
> > > > +static int intel_fb_check_offsets(const struct drm_mode_fb_cmd2 
> > > > *mode_cmd)
> > > > +{
> > > > +   uint32_t format = mode_cmd->pixel_format;
> > > > +   int num_planes = drm_format_num_planes(format);
> > > > +   int i;
> > > > +
> > > > +   for (i = 0; i < num_planes; i++) {
> > > > +   unsigned int cpp;
> > > > +
> > > > +   switch (format) {
> > > > +   case DRM_FORMAT_YUYV:
> > > > +   case DRM_FORMAT_UYVY:
> > > > +   case DRM_FORMAT_YVYU:
> > > > +   case DRM_FORMAT_VYUY:
> > > > +   cpp = 4;
> > > > +   break;
> > > > +   default:
> > > > +   cpp = drm_format_plane_cpp(format, i);
> > > 
> > > I didn't ask for a helper in drm_fourcc.c for macropixel blocksize? Shame
> > > on me!
> > 
> > You did, long ago. I just couldn't be bothered to go and see what we
> > need to do there. Now that I do, it doesn't look like we've gained
> > any new formats that would need special treatment, so I suppose I
> > could just reuse this guy as is.
> 
> Any ideas for the name? Anything I can come up with sounds stupid.
> The _cpp() precedent makes me want to do _cpm(), but that looks
> totally stupid. _macropixel_size() perhaps? Doesn't match the _cpp()
> Maybe rename the _cpp() to _pixel_size() to match? Dunno. Ideas?

I've pushed everything but this last patch to dinq. Thanks for the
reviews.

There are two open questions with this patch: first one is about
moving the helper to the core, and the second one has to do with
tests. Namely, I can't recall where I put the ones I had written,
so I need to try and dig them up.

> 
> > 
> > > Anyway, looks all good and I didn't spot anything else amiss while
> > > re-reading the series.
> > > 
> > > Another wishlist item: Extracting intel_framebuffer.c might be a good
> > > idea.
> > > -Daniel
> > > 
> > > > +   break;
> > > > +   }
> > > > +
> > > > +   if (mode_cmd->offsets[i] % cpp) {
> > > > +   DRM_DEBUG("fb plane %d offset 0x%08x not 
> > > > (macro)pixel aligned\n",
> > > > + i, mode_cmd->offsets[i]);
> > > > +   return -EINVAL;
> > > > +   }
> > > > +   }
> > > > +
> > > > +   return 0;
> > > > +}
> > > > +
> > > >  static int intel_framebuffer_init(struct drm_device *dev,
> > > >   struct intel_framebuffer *intel_fb,
> > > >   struct drm_mode_fb_cmd2 *mode_cmd,
> > > > @@ -15514,9 +15545,9 @@ static int intel_framebuffer_init(struct 
> > > > drm_device *dev,
> > > > return -EINVAL;
> > > > }
> > > >  
> > > > -   /* FIXME need to adjust LINOFF/TILEOFF accordingly. */
> > > > -   if (mode_cmd->offsets[0] != 0)
> > > > -   return -EINVAL;
> > > > +   ret = intel_fb_check_offsets(mode_cmd);
> > > > +   if (ret)
> > > > +   return ret;
> > > >  
> > > > drm_helper_mode_fill_fb_struct(_fb->base, mode_cmd);
 > > >  intel_fb->obj = obj;
> > > > -- 
> > > > 2.7.4
> > > > 
> > > > ___
> > > > 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
> > 
> > -- 
> > Ville Syrjälä
> > Intel OTC
> > 

Re: [Intel-gfx] [PATCH v4 6/6] drm/i915/huc: Add BXT HuC Loading Support

[Dave Gordon]

On 04/08/16 09:16, Peter Antoine wrote:

This patch adds the HuC Loading for the BXT.
Version 1.7 of the HuC firmware.

v2: rebased.
v3: rebased.
changed file name to match the install package format.
v4: rebased.

Signed-off-by: Peter Antoine 
---
 drivers/gpu/drm/i915/intel_huc_loader.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_huc_loader.c 
b/drivers/gpu/drm/i915/intel_huc_loader.c
index 21393ad..3588a95 100644
--- a/drivers/gpu/drm/i915/intel_huc_loader.c
+++ b/drivers/gpu/drm/i915/intel_huc_loader.c
@@ -49,6 +49,9 @@
 #define I915_SKL_HUC_UCODE "i915/skl_huc_ver01_07_1398.bin"
 MODULE_FIRMWARE(I915_SKL_HUC_UCODE);

+#define I915_BXT_HUC_UCODE "i915/bxt_huc_ver01_07_1398.bin"
+MODULE_FIRMWARE(I915_BXT_HUC_UCODE);


We don't really want to use this format for the firmware name.
But we'll fix that in the next version, when the naming gets
unified across all the uC devices :) So

Reviewed-by: Dave Gordon 


 /**
  * intel_huc_load_ucode() - DMA's the firmware
  * @dev: the drm device
@@ -157,6 +160,10 @@ void intel_huc_init(struct drm_device *dev)
fw_path = I915_SKL_HUC_UCODE;
huc_fw->major_ver_wanted = 1;
huc_fw->minor_ver_wanted = 7;
+   } else if (IS_BROXTON(dev_priv)) {
+   fw_path = I915_BXT_HUC_UCODE;
+   huc_fw->major_ver_wanted = 1;
+   huc_fw->minor_ver_wanted = 7;
}

if (fw_path == NULL)



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

Re: [Intel-gfx] [PATCH 15/33] drm/i915: Track pinned vma inside guc

[Dave Gordon]

On 07/08/16 15:45, Chris Wilson wrote:

Since the guc allocates and pins and object into the GGTT for its usage,
it is more natural to use that pinned VMA as our resource cookie.


Well it isn't really any more natural, as we hardly ever care about the 
mapping, whereas we more frequently work with the object. So it just 
seems to introduce an unnecessary extra level of indirection as we go 
from vma to object to whatever we really want.



Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_debugfs.c|  10 +--
 drivers/gpu/drm/i915/i915_guc_submission.c | 131 ++---
 drivers/gpu/drm/i915/intel_guc.h   |   9 +-
 drivers/gpu/drm/i915/intel_guc_loader.c|   7 +-
 4 files changed, 77 insertions(+), 80 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index b41c05767def..e2a9fc353ef3 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2524,15 +2524,15 @@ static int i915_guc_log_dump(struct seq_file *m, void 
*data)
struct drm_info_node *node = m->private;
struct drm_device *dev = node->minor->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
-   struct drm_i915_gem_object *log_obj = dev_priv->guc.log_obj;
-   u32 *log;
+   struct drm_i915_gem_object *obj;


It is completely unnecessary (and undesirable) to rename this local. A 
variable called 'obj' could be any sort of an object, but we know that 
we are dealing with *here* is a *specific* object that holds the pages 
of GuC log data, so it should have it a name that tells us so.



int i = 0, pg;

-   if (!log_obj)
+   if (!dev_priv->guc.log)
return 0;

-   for (pg = 0; pg < log_obj->base.size / PAGE_SIZE; pg++) {
-   log = kmap_atomic(i915_gem_object_get_page(log_obj, pg));
+   obj = dev_priv->guc.log->obj;
+   for (pg = 0; pg < obj->base.size / PAGE_SIZE; pg++) {
+   u32 *log = kmap_atomic(i915_gem_object_get_page(obj, pg));

for (i = 0; i < PAGE_SIZE / sizeof(u32); i += 4)
seq_printf(m, "0x%08x 0x%08x 0x%08x 0x%08x\n",
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 03a5cef353eb..f56d68173ae6 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -183,7 +183,7 @@ static int guc_update_doorbell_id(struct intel_guc *guc,
  struct i915_guc_client *client,
  u16 new_id)
 {
-   struct sg_table *sg = guc->ctx_pool_obj->pages;
+   struct sg_table *sg = guc->ctx_pool->obj->pages;


Hi-ho, hi-ho, it's off to RAM we go.
Notice the extra '->'


void *doorbell_bitmap = guc->doorbell_bitmap;
struct guc_doorbell_info *doorbell;
struct guc_context_desc desc;
@@ -325,8 +325,8 @@ static void guc_init_proc_desc(struct intel_guc *guc,
 static void guc_init_ctx_desc(struct intel_guc *guc,
  struct i915_guc_client *client)
 {
-   struct drm_i915_gem_object *client_obj = client->client_obj;
struct drm_i915_private *dev_priv = guc_to_i915(guc);
+   struct drm_i915_gem_object *client_obj = client->client->obj;


*Ugh*


struct intel_engine_cs *engine;
struct i915_gem_context *ctx = client->owner;
struct guc_context_desc desc;
@@ -380,7 +380,7 @@ static void guc_init_ctx_desc(struct intel_guc *guc,
 * The doorbell, process descriptor, and workqueue are all parts
 * of the client object, which the GuC will reference via the GGTT
 */
-   gfx_addr = i915_gem_obj_ggtt_offset(client_obj);
+   gfx_addr = client->client->node.start;


Insufficient abstraction.

If you want VMAs to be a primary sort of thing for code that isn't 
primarily about mappings to nonetheless work with, there should be an 
abstraction layer (macros or trivial inline accessors) to retrieve the 
things that code cares about from the 'VMA'.


gfx_addr = i915_vma_ggtt_addr(vma); // Or something

GuC code shouldn't have to mention 'node' or any other of the internals 
of a VMA or the underlying DRM memory-manager structure.



desc.db_trigger_phy = sg_dma_address(client_obj->pages->sgl) +
client->doorbell_offset;
desc.db_trigger_cpu = (uintptr_t)client->client_base +
@@ -397,7 +397,7 @@ static void guc_init_ctx_desc(struct intel_guc *guc,
desc.desc_private = (uintptr_t)client;

/* Pool context is pinned already */
-   sg = guc->ctx_pool_obj->pages;
+   sg = guc->ctx_pool->obj->pages;
sg_pcopy_from_buffer(sg->sgl, sg->nents, , sizeof(desc),
 sizeof(desc) * client->ctx_index);
 }
@@ -410,7 +410,7 @@ static void guc_fini_ctx_desc(struct intel_guc *guc,

memset(, 0, 

[Intel-gfx] [PATCH 0/2] capture error context

[Arun Siluvery]

and one other small change.

Arun Siluvery (1):
  drm/i915/error: Use yesno() to report iommu enable status

Dave Gordon (1):
  drm/i915/error: capture errored context based on request context-id

 drivers/gpu/drm/i915/i915_drv.h   |  2 ++
 drivers/gpu/drm/i915/i915_gpu_error.c | 48 +--
 2 files changed, 36 insertions(+), 14 deletions(-)

-- 
1.9.1

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

[Intel-gfx] [PATCH 1/2] drm/i915/error: Use yesno() to report iommu enable status

[Arun Siluvery]

Signed-off-by: Arun Siluvery 
---
 drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index eecb870..3209f6a 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -363,7 +363,7 @@ int i915_error_state_to_str(struct drm_i915_error_state_buf 
*m,
err_printf(m, "PCI Subsystem: %04x:%04x\n",
   dev->pdev->subsystem_vendor,
   dev->pdev->subsystem_device);
-   err_printf(m, "IOMMU enabled?: %d\n", error->iommu);
+   err_printf(m, "IOMMU enabled?: %s\n", yesno(error->iommu == 1));
 
if (HAS_CSR(dev)) {
struct intel_csr *csr = _priv->csr;
-- 
1.9.1

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

[Intel-gfx] [PATCH 2/2] drm/i915/error: capture errored context based on request context-id

[Arun Siluvery]

From: Dave Gordon 

Context capture hasn't worked for a while now, since the introduction of
execlists because the function that records active context is using CCID
register but this register contents are not valid in Execlist mode; this
patch makes it work again by using a different way of identifying the
context of interest in execlist mode.

For: VIZ-2021
Cc: Chris Wilson 
Cc: Mika Kuoppala 
Signed-off-by: Dave Gordon 
Signed-off-by: Arun Siluvery 
---
 drivers/gpu/drm/i915/i915_drv.h   |  2 ++
 drivers/gpu/drm/i915/i915_gpu_error.c | 46 +--
 2 files changed, 35 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7971c76..94b9314 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -546,6 +546,8 @@ struct drm_i915_error_state {
u32 rc_psmi; /* sleep state */
u32 semaphore_mboxes[I915_NUM_ENGINES - 1];
 
+   u64 ctx_desc;
+
struct drm_i915_error_object {
int page_count;
u64 gtt_offset;
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 3209f6a..fa365ee 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -386,7 +386,8 @@ int i915_error_state_to_str(struct drm_i915_error_state_buf 
*m,
err_printf(m, "PGTBL_ER: 0x%08x\n", error->pgtbl_er);
err_printf(m, "FORCEWAKE: 0x%08x\n", error->forcewake);
err_printf(m, "DERRMR: 0x%08x\n", error->derrmr);
-   err_printf(m, "CCID: 0x%08x\n", error->ccid);
+   if (!i915.enable_execlists)
+   err_printf(m, "CCID: 0x%08x\n", error->ccid);
err_printf(m, "Missed interrupts: 0x%08lx\n", 
dev_priv->gpu_error.missed_irq_rings);
 
for (i = 0; i < dev_priv->num_fence_regs; i++)
@@ -526,9 +527,10 @@ int i915_error_state_to_str(struct 
drm_i915_error_state_buf *m,
}
 
if ((obj = ee->ctx)) {
-   err_printf(m, "%s --- HW Context = 0x%08x\n",
+   err_printf(m, "%s --- HW Context = 0x%08x, %d pages\n",
   dev_priv->engine[i].name,
-  lower_32_bits(obj->gtt_offset));
+  lower_32_bits(obj->gtt_offset),
+  obj->page_count);
print_error_obj(m, obj);
}
}
@@ -1069,16 +1071,29 @@ static void i915_gem_record_active_context(struct 
intel_engine_cs *engine,
 {
struct drm_i915_private *dev_priv = engine->i915;
struct drm_i915_gem_object *obj;
+   bool elsp_mode = i915.enable_execlists;
 
/* Currently render ring is the only HW context user */
-   if (engine->id != RCS || !error->ccid)
+   if (engine->id != RCS)
+   return;
+
+   /* contents of CCID are not valid in execlist mode of scheduling */
+   if (!elsp_mode && !error->ccid)
return;
 
list_for_each_entry(obj, _priv->mm.bound_list, global_list) {
+   u64 base;
+
if (!i915_gem_obj_ggtt_bound(obj))
continue;
 
-   if ((error->ccid & PAGE_MASK) == i915_gem_obj_ggtt_offset(obj)) 
{
+   base = i915_gem_obj_ggtt_offset(obj);
+
+   if (elsp_mode)
+   base += LRC_PPHWSP_PN * PAGE_SIZE;
+
+   if (((error->ccid & PAGE_MASK) == base) ||
+   (((base ^ ee->ctx_desc) & 0xF000ULL) == 0)) {
ee->ctx = i915_error_ggtt_object_create(dev_priv, obj);
break;
}
@@ -1090,6 +1105,7 @@ static void i915_gem_record_rings(struct drm_i915_private 
*dev_priv,
 {
struct i915_ggtt *ggtt = _priv->ggtt;
struct drm_i915_gem_request *request;
+   struct intel_engine_cs *engine;
int i, count;
 
if (dev_priv->semaphore_obj) {
@@ -1098,17 +1114,12 @@ static void i915_gem_record_rings(struct 
drm_i915_private *dev_priv,
  dev_priv->semaphore_obj);
}
 
-   for (i = 0; i < I915_NUM_ENGINES; i++) {
-   struct intel_engine_cs *engine = _priv->engine[i];
+   for_each_engine_masked(engine, dev_priv, dev_priv->gt.active_engines) {
struct drm_i915_error_engine *ee = >engine[i];
+   u64 ctx_desc;
 
ee->pid = -1;
-   ee->engine_id = -1;
-
-   if (!intel_engine_initialized(engine))
-   continue;
-
-   ee->engine_id = i;
+   ee->engine_id = engine->id;
 
error_record_engine_registers(error, engine, ee);
 

Re: [Intel-gfx] [PATCH] drm/i915: Restore DMC required version for Skylake (1.26)

[Vivi, Rodrigo]

On Wed, 2016-08-10 at 10:55 +0300, Jani Nikula wrote:
> On Wed, 10 Aug 2016, Rodrigo Vivi  wrote:
> > 
> > With commit 4aa7fb9c ("drm/i915/dmc: Step away from symbolic
> > links") we started loading the firmware version directly
> > instead of symbolic links.
> > 
> > With this VERSION_REQUIRED variables changed the meaning
> > from minimal required to exact version required. Along
> > with this change we started using the latest stable
> > DMC firmware as the required one 1.26.
> > 
> > This patch is correct. However in some merge this
> > change got missed and it was overwritten by the old
> > version.
> > 
> > 1.23 is unstable and can cause blank screens so let's
> > avoid it.
> > 
> > Cc: sta...@vger.kernel.org
> No. 4aa7fb9c is not in a stable released kernel. Please try 'dim
> fixes
> 4aa7fb9c'.
> 
> I guess 4aa7fb9c *not* having been released saves us from restoring
> 1.23
> to linux-firmware. However, v4.8-rc1 will still be busted if 1.23
> isn't
> restored to linux-firmware.

ok, I'm restoring per maintainers request, but I'm trying to warn that
it might be busted with 1.23 in place. Without it users will only have
warning and not the ideal power consumption.

> 
> BR,
> Jani.
> 
> 
> 
> > 
> > Cc: Jani Nikula 
> > Cc: Daniel Vetter 
> > Cc: Patrik Jakobsson 
> > Cc: Matthew Atwood 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97182
> > Signed-off-by: Rodrigo Vivi 
> > ---
> >  drivers/gpu/drm/i915/intel_csr.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_csr.c
> > b/drivers/gpu/drm/i915/intel_csr.c
> > index fb27d18..0efce3f 100644
> > --- a/drivers/gpu/drm/i915/intel_csr.c
> > +++ b/drivers/gpu/drm/i915/intel_csr.c
> > @@ -40,7 +40,7 @@ MODULE_FIRMWARE(I915_CSR_KBL);
> >  
> >  #define I915_CSR_SKL "i915/skl_dmc_ver1.bin"
> >  MODULE_FIRMWARE(I915_CSR_SKL);
> > -#define SKL_CSR_VERSION_REQUIRED   CSR_VERSION(1, 23)
> > +#define SKL_CSR_VERSION_REQUIRED   CSR_VERSION(1, 26)
> >  
> >  #define I915_CSR_BXT "i915/bxt_dmc_ver1.bin"
> >  MODULE_FIRMWARE(I915_CSR_BXT);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3] drm/i915: Initialize legacy semaphores from engine hw id indexed array

[Chris Wilson]

On Thu, Aug 11, 2016 at 03:50:17PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> Build the legacy semaphore initialisation array using the engine
> hardware ids instead of driver internal ones. This makes the
> static array size dependent only on the number of gen6 semaphore
> engines.
> 
> Also makes the per-engine semaphore wait and signal tables
> hardware id indexed saving some more space.
> 
> v2: Refactor I915_GEN6_NUM_ENGINES to GEN6_SEMAPHORE_LAST. (Chris Wilson)
> v3: More polish. (Chris Wilson)
> 
> Signed-off-by: Tvrtko Ursulin 

Reviewed-by: Chris Wilson 
(and for patch 1/2)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Ro.CI.BAT: failure for Shrink and lock the size static gen6 semaphore init array (rev3)

[Patchwork]

== Series Details ==

Series: Shrink and lock the size static gen6 semaphore init array (rev3)
URL   : https://patchwork.freedesktop.org/series/10949/
State : failure

== Summary ==

Series 10949v3 Shrink and lock the size static gen6 semaphore init array
http://patchwork.freedesktop.org/api/1.0/series/10949/revisions/3/mbox

Test gem_exec_suspend:
Subgroup basic-s3:
incomplete -> DMESG-WARN (fi-skl-i7-6700k)
Test kms_cursor_legacy:
Subgroup basic-cursor-vs-flip-legacy:
pass   -> SKIP   (ro-hsw-i7-4770r)
Subgroup basic-cursor-vs-flip-varying-size:
pass   -> SKIP   (ro-hsw-i7-4770r)
Subgroup basic-flip-vs-cursor-legacy:
fail   -> SKIP   (ro-hsw-i7-4770r)
pass   -> FAIL   (ro-bdw-i5-5250u)
Subgroup basic-flip-vs-cursor-varying-size:
pass   -> SKIP   (ro-hsw-i7-4770r)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass   -> SKIP   (ro-hsw-i7-4770r)
Subgroup basic-flip-vs-modeset:
pass   -> SKIP   (ro-hsw-i7-4770r)
Subgroup basic-flip-vs-wf_vblank:
pass   -> SKIP   (ro-hsw-i7-4770r)
Subgroup basic-plain-flip:
pass   -> SKIP   (ro-hsw-i7-4770r)
Test kms_frontbuffer_tracking:
Subgroup basic:
pass   -> SKIP   (ro-hsw-i7-4770r)
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-a:
pass   -> SKIP   (ro-hsw-i7-4770r)
Subgroup hang-read-crc-pipe-b:
pass   -> SKIP   (ro-hsw-i7-4770r)
Subgroup hang-read-crc-pipe-c:
pass   -> SKIP   (ro-hsw-i7-4770r)
Subgroup nonblocking-crc-pipe-a:
pass   -> SKIP   (ro-hsw-i7-4770r)
Subgroup nonblocking-crc-pipe-a-frame-sequence:
pass   -> SKIP   (ro-hsw-i7-4770r)
Subgroup nonblocking-crc-pipe-b:
pass   -> SKIP   (ro-hsw-i7-4770r)
Subgroup nonblocking-crc-pipe-b-frame-sequence:
pass   -> SKIP   (ro-hsw-i7-4770r)
Subgroup nonblocking-crc-pipe-c:
pass   -> SKIP   (ro-hsw-i7-4770r)
Subgroup nonblocking-crc-pipe-c-frame-sequence:
pass   -> SKIP   (ro-hsw-i7-4770r)
Subgroup read-crc-pipe-a:
pass   -> SKIP   (ro-hsw-i7-4770r)
Subgroup read-crc-pipe-a-frame-sequence:
pass   -> SKIP   (ro-hsw-i7-4770r)
Subgroup read-crc-pipe-b:
pass   -> SKIP   (ro-hsw-i7-4770r)
Subgroup read-crc-pipe-b-frame-sequence:
pass   -> SKIP   (ro-hsw-i7-4770r)
Subgroup read-crc-pipe-c:
pass   -> SKIP   (ro-hsw-i7-4770r)
Subgroup read-crc-pipe-c-frame-sequence:
pass   -> SKIP   (ro-hsw-i7-4770r)
Subgroup suspend-read-crc-pipe-a:
pass   -> SKIP   (ro-hsw-i7-4770r)
Subgroup suspend-read-crc-pipe-b:
pass   -> SKIP   (ro-hsw-i7-4770r)
Subgroup suspend-read-crc-pipe-c:
pass   -> SKIP   (ro-hsw-i7-4770r)
Test pm_rpm:
Subgroup basic-pci-d3-state:
pass   -> SKIP   (ro-hsw-i7-4770r)
Subgroup basic-rte:
pass   -> SKIP   (ro-hsw-i7-4770r)

fi-hsw-i7-4770k  total:244  pass:221  dwarn:0   dfail:0   fail:1   skip:22 
fi-kbl-qkkr  total:244  pass:187  dwarn:28  dfail:0   fail:3   skip:26 
fi-skl-i5-6260u  total:244  pass:224  dwarn:4   dfail:0   fail:2   skip:14 
fi-skl-i7-6700k  total:244  pass:208  dwarn:4   dfail:2   fail:2   skip:28 
fi-snb-i7-2600   total:244  pass:202  dwarn:0   dfail:0   fail:0   skip:42 
ro-bdw-i5-5250u  total:240  pass:218  dwarn:4   dfail:0   fail:2   skip:16 
ro-bdw-i7-5600u  total:240  pass:207  dwarn:0   dfail:0   fail:1   skip:32 
ro-bsw-n3050 total:240  pass:194  dwarn:0   dfail:0   fail:4   skip:42 
ro-hsw-i3-4010u  total:240  pass:214  dwarn:0   dfail:0   fail:0   skip:26 
ro-hsw-i7-4770r  total:240  pass:185  dwarn:0   dfail:0   fail:0   skip:55 
ro-ilk1-i5-650   total:235  pass:173  dwarn:0   dfail:0   fail:2   skip:60 
ro-ivb-i7-3770   total:240  pass:205  dwarn:0   dfail:0   fail:0   skip:35 
ro-ivb2-i7-3770  total:240  pass:209  dwarn:0   dfail:0   fail:0   skip:31 
ro-skl3-i5-6260u total:240  pass:222  dwarn:0   dfail:0   fail:4   skip:14 
ro-bdw-i7-5557U failed to connect after reboot
ro-byt-n2820 failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1838/

3c6050a drm-intel-nightly: 2016y-08m-11d-10h-34m-38s UTC integration manifest
db642c1 drm/i915: Initialize legacy semaphores from engine hw id indexed array
42f9b20 drm/i915: Add enum for hardware engine identifiers

[Intel-gfx] [PATCH v3] drm/i915: Initialize legacy semaphores from engine hw id indexed array

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Build the legacy semaphore initialisation array using the engine
hardware ids instead of driver internal ones. This makes the
static array size dependent only on the number of gen6 semaphore
engines.

Also makes the per-engine semaphore wait and signal tables
hardware id indexed saving some more space.

v2: Refactor I915_GEN6_NUM_ENGINES to GEN6_SEMAPHORE_LAST. (Chris Wilson)
v3: More polish. (Chris Wilson)

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_ringbuffer.c | 55 +
 drivers/gpu/drm/i915/intel_ringbuffer.h |  7 +++--
 2 files changed, 34 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index ed19868df9c6..7dd19771dd52 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1385,8 +1385,7 @@ static int gen6_signal(struct drm_i915_gem_request *req)
 {
struct intel_ring *ring = req->ring;
struct drm_i915_private *dev_priv = req->i915;
-   struct intel_engine_cs *useless;
-   enum intel_engine_id id;
+   struct intel_engine_cs *engine;
int ret, num_rings;
 
num_rings = INTEL_INFO(dev_priv)->num_rings;
@@ -1394,9 +1393,13 @@ static int gen6_signal(struct drm_i915_gem_request *req)
if (ret)
return ret;
 
-   for_each_engine_id(useless, dev_priv, id) {
-   i915_reg_t mbox_reg = req->engine->semaphore.mbox.signal[id];
+   for_each_engine(engine, dev_priv) {
+   i915_reg_t mbox_reg;
+
+   if (!(BIT(engine->hw_id) & GEN6_SEMAPHORES_MASK))
+   continue;
 
+   mbox_reg = req->engine->semaphore.mbox.signal[engine->hw_id];
if (i915_mmio_reg_valid(mbox_reg)) {
intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
intel_ring_emit_reg(ring, mbox_reg);
@@ -1543,7 +1546,7 @@ gen6_ring_sync_to(struct drm_i915_gem_request *req,
u32 dw1 = MI_SEMAPHORE_MBOX |
  MI_SEMAPHORE_COMPARE |
  MI_SEMAPHORE_REGISTER;
-   u32 wait_mbox = signal->engine->semaphore.mbox.wait[req->engine->id];
+   u32 wait_mbox = signal->engine->semaphore.mbox.wait[req->engine->hw_id];
int ret;
 
WARN_ON(wait_mbox == MI_SEMAPHORE_SYNC_INVALID);
@@ -2671,41 +2674,41 @@ static void intel_ring_init_semaphores(struct 
drm_i915_private *dev_priv,
 * initialized as INVALID.  Gen8 will initialize the
 * sema between VCS2 and RCS later.
 */
-   for (i = 0; i < I915_NUM_ENGINES; i++) {
+   for (i = 0; i < GEN6_NUM_SEMAPHORES; i++) {
static const struct {
u32 wait_mbox;
i915_reg_t mbox_reg;
-   } sem_data[I915_NUM_ENGINES][I915_NUM_ENGINES] = {
-   [RCS] = {
-   [VCS] =  { .wait_mbox = 
MI_SEMAPHORE_SYNC_RV,  .mbox_reg = GEN6_VRSYNC },
-   [BCS] =  { .wait_mbox = 
MI_SEMAPHORE_SYNC_RB,  .mbox_reg = GEN6_BRSYNC },
-   [VECS] = { .wait_mbox = 
MI_SEMAPHORE_SYNC_RVE, .mbox_reg = GEN6_VERSYNC },
+   } sem_data[GEN6_NUM_SEMAPHORES][GEN6_NUM_SEMAPHORES] = {
+   [RCS_HW] = {
+   [VCS_HW] =  { .wait_mbox = 
MI_SEMAPHORE_SYNC_RV,  .mbox_reg = GEN6_VRSYNC },
+   [BCS_HW] =  { .wait_mbox = 
MI_SEMAPHORE_SYNC_RB,  .mbox_reg = GEN6_BRSYNC },
+   [VECS_HW] = { .wait_mbox = 
MI_SEMAPHORE_SYNC_RVE, .mbox_reg = GEN6_VERSYNC },
},
-   [VCS] = {
-   [RCS] =  { .wait_mbox = 
MI_SEMAPHORE_SYNC_VR,  .mbox_reg = GEN6_RVSYNC },
-   [BCS] =  { .wait_mbox = 
MI_SEMAPHORE_SYNC_VB,  .mbox_reg = GEN6_BVSYNC },
-   [VECS] = { .wait_mbox = 
MI_SEMAPHORE_SYNC_VVE, .mbox_reg = GEN6_VEVSYNC },
+   [VCS_HW] = {
+   [RCS_HW] =  { .wait_mbox = 
MI_SEMAPHORE_SYNC_VR,  .mbox_reg = GEN6_RVSYNC },
+   [BCS_HW] =  { .wait_mbox = 
MI_SEMAPHORE_SYNC_VB,  .mbox_reg = GEN6_BVSYNC },
+   [VECS_HW] = { .wait_mbox = 
MI_SEMAPHORE_SYNC_VVE, .mbox_reg = GEN6_VEVSYNC },
},
-   [BCS] = {
-   [RCS] =  { .wait_mbox = 
MI_SEMAPHORE_SYNC_BR,  .mbox_reg = GEN6_RBSYNC },
-   [VCS] =  { .wait_mbox = 
MI_SEMAPHORE_SYNC_BV,  

Re: [Intel-gfx] [PATCH v2] drm/i915: Initialize legacy semaphores from engine hw id indexed array

[Tvrtko Ursulin]

On 11/08/16 12:20, Chris Wilson wrote:

On Thu, Aug 11, 2016 at 12:05:58PM +0100, Tvrtko Ursulin wrote:

@@ -1394,9 +1393,13 @@ static int gen6_signal(struct drm_i915_gem_request *req)
if (ret)
return ret;

-   for_each_engine_id(useless, dev_priv, id) {
-   i915_reg_t mbox_reg = req->engine->semaphore.mbox.signal[id];
+   for_each_engine(engine, dev_priv) {
+   i915_reg_t mbox_reg;
+
+   if (engine->hw_id > GEN6_SEMAPHORE_LAST)
+   continue;


Yeah, this makes more sense to me...


diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index ac568808aeb1..c2d8677b5b9f 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -277,11 +277,12 @@ struct intel_engine_cs {
u32 sync_seqno[I915_NUM_ENGINES-1];

union {
+#define GEN6_SEMAPHORE_LAST VECS_HW
struct {
/* our mbox written by others */
-   u32 wait[I915_NUM_ENGINES];
+   u32 wait[GEN6_SEMAPHORE_LAST + 1];


but I agree with your hesistation here.

#define GEN6_SEMAPHORE_LAST VECS_HW
#define GEN6_NUM_SEMAPHORES (GEN6_SEMAPHORE_LAST_HW + 1)
#define GEN6_MASK_SEMAPHORES GENMASK(GEN6_SEMAPHORE_LAST, 0)

if (!(BIT(engine->hw_id) & GEN6_SEMAPHORES_MASK))
continue;

(can't decide on NUM/MASK_SEM or SEM_COUNT/MASK)

would that look better?


Yeah it is better, will do that with NUM/MASK.

Regards,

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

Re: [Intel-gfx] [PATCH v7 3/5] drm/i915: Check pixel rate for DP to VGA dongle

[Ville Syrjälä]

On Thu, Aug 11, 2016 at 03:26:42PM +0300, Mika Kahola wrote:
> On Thu, 2016-08-11 at 12:56 +0200, Daniel Vetter wrote:
> > On Thu, Aug 11, 2016 at 01:51:42PM +0300, Ville Syrjälä wrote:
> > > On Thu, Aug 11, 2016 at 12:43:39PM +0300, Mika Kahola wrote:
> > > > On Thu, 2016-08-11 at 10:18 +0300, Ville Syrjälä wrote:
> > > > > On Mon, Aug 08, 2016 at 04:00:28PM +0300, Mika Kahola wrote:
> > > > > > Filter out a mode that exceeds the max pixel rate setting
> > > > > > for DP to VGA dongle. This is defined in DPCD register 0x81
> > > > > > if detailed cap info i.e. info field is 4 bytes long and
> > > > > > it is available for DP downstream port.
> > > > > > 
> > > > > > The register defines the pixel rate divided by 8 in MP/s.
> > > > > > 
> > > > > > v2: DPCD read outs and computation moved to drm (Ville, Daniel)
> > > > > > v3: Sink pixel rate computation moved to drm_dp_max_sink_dotclock()
> > > > > > function (Daniel)
> > > > > > v4: Use of drm_dp_helper.c routines to compute max pixel clock 
> > > > > > (Ville)
> > > > > > v5: Use of intel_dp->downstream_ports to read out port capabilities.
> > > > > > Code restructuring (Ville)
> > > > > > v6: Move DP branch device check to drm_dp_helper.c (Daniel)
> > > > > > 
> > > > > > Signed-off-by: Mika Kahola 
> > > > > > ---
> > > > > >  drivers/gpu/drm/i915/intel_dp.c | 25 -
> > > > > >  1 file changed, 24 insertions(+), 1 deletion(-)
> > > > > > 
> > > > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > > > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > > > index 21b04c3..e990c8b 100644
> > > > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > > > @@ -190,6 +190,26 @@ intel_dp_max_data_rate(int max_link_clock, int 
> > > > > > max_lanes)
> > > > > > return (max_link_clock * max_lanes * 8) / 10;
> > > > > >  }
> > > > > >  
> > > > > > +static int
> > > > > > +intel_dp_downstream_max_dotclock(struct intel_dp *intel_dp, int 
> > > > > > dotclk)
> > > > > > +{
> > > > > 
> > > > > I would just
> > > > > 
> > > > > {
> > > > >   int max_dotclk = dev_priv->max_dotclk_freq;
> > > > > 
> > > > >   ds_max_dotclk = ...;
> > > > >   if (ds_dotclk != 0)
> > > > >   max_dotclk = min(max_dotclk, ds_max_dotclk);
> > > > > 
> > > > >   return max_dotclk;
> > > > > }
> > > > > 
> > > > > > +   int ds_dotclk;
> > > > > > +   int type;
> > > > > > +
> > > > > > +   ds_dotclk = drm_dp_downstream_max_clock(intel_dp->dpcd,
> > > > > > +   
> > > > > > intel_dp->downstream_ports);
> > > > > > +
> > > > > > +   if (ds_dotclk == 0)
> > > > > > +   return dotclk;
> > > > > > +
> > > > > > +   type = intel_dp->downstream_ports[0] & DP_DS_PORT_TYPE_MASK;
> > > > > > +   
> > > > > > +   if (type != DP_DS_PORT_TYPE_VGA)
> > > > > > +   return dotclk;
> > > > > 
> > > > > Why isn't drm_dp_downstream_max_clock() handling all of it already?
> > > > > Why are we even checking for !=VGA?
> > > > The routine drm_dp_downstream_max_clock returns the clock rate which can
> > > > be dotclock (VGA only) or TMDS clock (for DVI, HDMI, DP++). Here, we
> > > > need to have a check for this as we are only interested to update VGA
> > > > dotclock value.
> > > 
> > > We should handle it all. Actually I'm not even sure how we're supposed
> > > to deal with the downstream port max TMDS clock since for HDMI that
> > > depends on the bpc, but since this is about a DP->HDMI conversion, I
> > > don't know if we have to take the downstream port max TMDS clock into
> > > account when choosing the bpc over the DP link as well. I suppose that's
> > > possible if the dongle can't change change the bpc, and instead just
> > > passes things through. I think this is one of those places where the
> > > DP spec is way too unclear. But for DP->VGA there is no clock going out
> > > the other end, so it must be just about the limits of the DP input or
> > > the DAC.
> > 
> > I guess we should defensively assume that the tmds clock limit is both for
> > the input and the output signal, worst case, for the dp->hdmi dongle?
> > Except when it's a passive level-shifter only one ofc.
> > -Daniel
> So, we should respect dongles both tmds and bpc values. I thought that
> tmds clock checks was already covered by Ville's DP dual mode patch
> series?

That doesn't deal with active DP->HDMI converters, which is what this
DPCD stuff will have to deal with.

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

Re: [Intel-gfx] [PATCH REBASED v10 6/6] drm/i915/skl: Update DDB values atomically with wms/plane attrs

[Maarten Lankhorst]

Hey,

Op 10-08-16 om 16:28 schreef Lyude:
> Now that we can hook into update_crtcs and control the order in which we
> update CRTCs at each modeset, we can finish the final step of fixing
> Skylake's watermark handling by performing DDB updates at the same time
> as plane updates and watermark updates.
>
> The first major change in this patch is skl_update_crtcs(), which
> handles ensuring that we order each CRTC update in our atomic commits
> properly so that they honor the DDB flush order.
>
> The second major change in this patch is the order in which we flush the
> pipes. While the previous order may have worked, it can't be used in
> this approach since it no longer will do the right thing. For example,
> using the old ddb flush order:
>
> We have pipes A, B, and C enabled, and we're disabling C. Initial ddb
> allocation looks like this:
>
> |   A   |   B   |xxx|
>
> Since we're performing the ddb updates after performing any CRTC
> disablements in intel_atomic_commit_tail(), the space to the right of
> pipe B is unallocated.
>
> 1. Flush pipes with new allocation contained into old space. None
>apply, so we skip this
> 2. Flush pipes having their allocation reduced, but overlapping with a
>previous allocation. None apply, so we also skip this
> 3. Flush pipes that got more space allocated. This applies to A and B,
>giving us the following update order: A, B
>
> This is wrong, since updating pipe A first will cause it to overlap with
> B and potentially burst into flames. Our new order (see the code
> comments for details) would update the pipes in the proper order: B, A.
>
> As well, we calculate the order for each DDB update during the check
> phase, and reference it later in the commit phase when we hit
> skl_update_crtcs().
>
> This long overdue patch fixes the rest of the underruns on Skylake.
>
> Changes since v1:
>  - Add skl_ddb_entry_write() for cursor into skl_write_cursor_wm()
> Changes since v2:
>  - Use the method for updating CRTCs that Ville suggested
>  - In skl_update_wm(), only copy the watermarks for the crtc that was
>passed to us
> Changes since v3:
>  - Small comment fix in skl_ddb_allocation_overlaps()
>
> Fixes: 0e8fb7ba7ca5 ("drm/i915/skl: Flush the WM configuration")
> Fixes: 8211bd5bdf5e ("drm/i915/skl: Program the DDB allocation")
> [omitting CC for stable, since this patch will need to be changed for
> such backports first]
This series breaks on kms_atomic_transition.plane-all-transition (just uploaded 
the changed tests to igt, please rebuild)

[ 5455.543871] [drm:verify_wm_state.isra.72 [i915]] *ERROR* mismatch in DDB 
state pipe A plane 1 (expected (0,0), found (0,860))

There's also a WARN_ON(... && total_data_rate == 0) which you need to comment 
out for the tests to pass cleanly.

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

Re: [Intel-gfx] [PATCH v3 2/4] drm/i915: Add lspcon support for I915 driver

[Ville Syrjälä]

On Thu, Aug 11, 2016 at 02:36:23PM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 8/11/2016 12:33 PM, Ville Syrjälä wrote:
> > On Tue, Jul 05, 2016 at 06:35:48PM +0530, Shashank Sharma wrote:
> >> This patch adds a new file, to accommodate lspcon support
> >> for I915 driver. These functions probe, detect, initialize
> >> and configure an on-board lspcon device during the driver
> >> init time.
> >>
> >> Also, this patch adds a small structure for lspcon device,
> >> which will provide the runtime status of the device.
> >>
> >> V2: addressed ville's review comments
> >> - Clean the leftover macros from previous patch set
> >>
> >> V3: Rebase
> >>
> >> Signed-off-by: Shashank Sharma 
> >> Signed-off-by: Akashdeep Sharma 
> >> Reviewed-by: Rodrigo Vivi 
> >> ---
> >>   drivers/gpu/drm/i915/Makefile   |   1 +
> >>   drivers/gpu/drm/i915/intel_drv.h|  13 +++-
> >>   drivers/gpu/drm/i915/intel_lspcon.c | 145 
> >> 
> >>   3 files changed, 158 insertions(+), 1 deletion(-)
> >>   create mode 100644 drivers/gpu/drm/i915/intel_lspcon.c
> >>
> >> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> >> index 618293c..64cd373 100644
> >> --- a/drivers/gpu/drm/i915/Makefile
> >> +++ b/drivers/gpu/drm/i915/Makefile
> >> @@ -95,6 +95,7 @@ i915-y += dvo_ch7017.o \
> >>  intel_dvo.o \
> >>  intel_hdmi.o \
> >>  intel_i2c.o \
> >> +intel_lspcon.o \
> >>  intel_lvds.o \
> >>  intel_panel.o \
> >>  intel_sdvo.o \
> >> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> >> b/drivers/gpu/drm/i915/intel_drv.h
> >> index e6a24d2..e6982cf 100644
> >> --- a/drivers/gpu/drm/i915/intel_drv.h
> >> +++ b/drivers/gpu/drm/i915/intel_drv.h
> >> @@ -922,12 +922,19 @@ struct intel_dp {
> >>bool compliance_test_active;
> >>   };
> >>   
> >> +struct intel_lspcon {
> >> +  bool active;
> >> +  enum drm_lspcon_mode mode_of_op;
> > I'd call this just 'mode'
> I dont want reader to get confused this with a videomode, so made it 
> more clear :)
> Do you think we can keep it this way ?

I don't think there's any real chance of a mixup there. It's always going
to used as lspcon.mode I think, and the types are incompatible anyway.

> >> +  struct drm_dp_aux *aux;
> >> +};
> >> +
> >>   struct intel_digital_port {
> >>struct intel_encoder base;
> >>enum port port;
> >>u32 saved_port_bits;
> >>struct intel_dp dp;
> >>struct intel_hdmi hdmi;
> >> +  struct intel_lspcon lspcon;
> >>enum irqreturn (*hpd_pulse)(struct intel_digital_port *, bool);
> >>bool release_cl2_override;
> >>uint8_t max_lanes;
> >> @@ -1478,7 +1485,6 @@ bool intel_hdmi_compute_config(struct intel_encoder 
> >> *encoder,
> >>   struct intel_crtc_state *pipe_config);
> >>   void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi *hdmi, bool 
> >> enable);
> >>   
> >> -
> >>   /* intel_lvds.c */
> >>   void intel_lvds_init(struct drm_device *dev);
> >>   struct intel_encoder *intel_get_lvds_encoder(struct drm_device *dev);
> >> @@ -1779,4 +1785,9 @@ int intel_color_check(struct drm_crtc *crtc, struct 
> >> drm_crtc_state *state);
> >>   void intel_color_set_csc(struct drm_crtc_state *crtc_state);
> >>   void intel_color_load_luts(struct drm_crtc_state *crtc_state);
> >>   
> >> +/* intel_lspcon.c */
> >> +bool lspcon_init(struct intel_digital_port *intel_dig_port);
> >> +enum drm_connector_status
> >> +lspcon_ls_mode_detect(struct drm_connector *connector, bool force);
> >> +bool is_lspcon_active(struct intel_digital_port *dig_port);
> >>   #endif /* __INTEL_DRV_H__ */
> >> diff --git a/drivers/gpu/drm/i915/intel_lspcon.c 
> >> b/drivers/gpu/drm/i915/intel_lspcon.c
> >> new file mode 100644
> >> index 000..fdeff71
> >> --- /dev/null
> >> +++ b/drivers/gpu/drm/i915/intel_lspcon.c
> >> @@ -0,0 +1,145 @@
> >> +/*
> >> + * Copyright © 2016 Intel Corporation
> >> + *
> >> + * Permission is hereby granted, free of charge, to any person obtaining a
> >> + * copy of this software and associated documentation files (the 
> >> "Software"),
> >> + * to deal in the Software without restriction, including without 
> >> limitation
> >> + * the rights to use, copy, modify, merge, publish, distribute, 
> >> sublicense,
> >> + * and/or sell copies of the Software, and to permit persons to whom the
> >> + * Software is furnished to do so, subject to the following conditions:
> >> + *
> >> + * The above copyright notice and this permission notice (including the 
> >> next
> >> + * paragraph) shall be included in all copies or substantial portions of 
> >> the
> >> + * Software.
> >> + *
> >> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 
> >> EXPRESS OR
> >> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 
> >> MERCHANTABILITY,
> >> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT 
> >> SHALL

Re: [Intel-gfx] [PATCH v3 1/4] drm: Helper for lspcon in drm_dp_dual_mode

[Ville Syrjälä]

On Thu, Aug 11, 2016 at 02:14:10PM +0530, Sharma, Shashank wrote:
> Thanks for the review, Ville.
> 
> My comments, inline.
> 
> Regards
> 
> Shashank
> 
> 
> On 8/11/2016 12:19 PM, Ville Syrjälä wrote:
> > On Tue, Jul 05, 2016 at 06:35:47PM +0530, Shashank Sharma wrote:
> >> This patch adds lspcon support in dp_dual_mode helper.
> >> lspcon is essentially a dp->hdmi dongle with dual personality.
> >>
> >> LS mode: It works as a passive dongle, by level shifting DP++
> >> signals to HDMI signals, in LS mode.
> >> PCON mode: It works as a protocol converter active dongle
> >> in pcon mode, by converting DP++ outputs to HDMI 2.0 outputs.
> >>
> >> This patch adds support for lspcon detection and mode set
> >> switch operations, as a dp dual mode dongle.
> >>
> >> v2: Addressed review comments from Ville
> >> - add adaptor id for lspcon devices (0x08), use it to identify lspcon
> >> - change function names
> >>old: drm_lspcon_get_current_mode/drm_lspcon_change_mode
> >>new: drm_lspcon_get_mode/drm_lspcon_set_mode
> >> - change drm_lspcon_get_mode type to int, to match
> >>drm_dp_dual_mode_get_tmds_output
> >> - change 'err' to 'ret' to match the rest of the functions
> >> - remove pointless typecasting during call to dual_mode_read
> >> - fix the but while setting value of data, while writing lspcon mode
> >> - fix indentation
> >> - change mdelay(10) -> msleep(10)
> >> - return ETIMEDOUT instead of EFAULT, when lspcon mode change times out
> >> - Add an empty line to separate std regs macros and lspcon regs macros
> >>Indent bit definition
> >>
> >> v3: Addressed review comments from Rodrigo
> >> - change macro name from DP_DUAL_MODE_TYPE_LSPCON to
> >>DP_DUAL_MODE_TYPE_HAS_DPCD for better readability
> >> - change macro name from DP_DUAL_MODE_LSPCON_MODE_PCON to
> >>DP_DUAL_MODE_LSPCON_MODE_PCON for better readability
> >> - add comment for MCA specific offsets like 0x40 and 0x41
> >> - remove DP_DUAL_MODE_REV_TYPE2 check while checking lspcon adapter id
> >>
> >> Signed-off-by: Shashank Sharma 
> >> ---
> >>   drivers/gpu/drm/drm_dp_dual_mode_helper.c | 103 
> >> ++
> >>   include/drm/drm_dp_dual_mode_helper.h |  26 
> >>   2 files changed, 129 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c 
> >> b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> >> index a7b2a75..4f89e0b 100644
> >> --- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> >> +++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
> >> @@ -148,6 +148,14 @@ static bool is_type2_adaptor(uint8_t adaptor_id)
> >>  DP_DUAL_MODE_REV_TYPE2);
> >>   }
> >>   
> >> +bool is_lspcon_adaptor(const char hdmi_id[DP_DUAL_MODE_HDMI_ID_LEN],
> >> +  const uint8_t adaptor_id)
> >> +{
> >> +  return is_hdmi_adaptor(hdmi_id) &&
> >> +  (adaptor_id == (DP_DUAL_MODE_TYPE_TYPE2 |
> >> +  DP_DUAL_MODE_TYPE_HAS_DPCD));
> > Looks like an indent fail here.
> Can you please let me know, why do we call it indent fail ? checkpatch 
> doesn't complaint about this.

Stuff should line up after the opening '('

> >> +}
> >> +
> >>   /**
> >>* drm_dp_dual_mode_detect - Identify the DP dual mode adaptor
> >>* @adapter: I2C adapter for the DDC bus
> >> @@ -203,6 +211,8 @@ enum drm_dp_dual_mode_type 
> >> drm_dp_dual_mode_detect(struct i2c_adapter *adapter)
> >>ret = drm_dp_dual_mode_read(adapter, DP_DUAL_MODE_ADAPTOR_ID,
> >>_id, sizeof(adaptor_id));
> >>if (ret == 0) {
> >> +  if (is_lspcon_adaptor(hdmi_id, adaptor_id))
> >> +  return DRM_DP_DUAL_MODE_LSPCON;
> >>if (is_type2_adaptor(adaptor_id)) {
> >>if (is_hdmi_adaptor(hdmi_id))
> >>return DRM_DP_DUAL_MODE_TYPE2_HDMI;
> >> @@ -364,3 +374,96 @@ const char *drm_dp_get_dual_mode_type_name(enum 
> >> drm_dp_dual_mode_type type)
> >>}
> >>   }
> >>   EXPORT_SYMBOL(drm_dp_get_dual_mode_type_name);
> >> +
> >> +/**
> >> + * drm_lspcon_get_current_mode: Get LSPCON's current mode of operation by
> >> + * by reading offset (0x80, 0x41)
> >> + * @i2c_adapter: I2C-over-aux adapter
> >> + * @current_mode: out vaiable, current lspcon mode of operation
> >> + *
> >> + * Returns:
> >> + * 0 on success, sets the current_mode value to appropriate mode
> >> + * -error on failure
> >> + */
> >> +int drm_lspcon_get_mode(struct i2c_adapter *adapter,
> >> +  enum drm_lspcon_mode *current_mode)
> > indent fail, I would just call it 'mode'
> I wanted to be more informative about what is the out parameter, I 
> though it makes it more readable
> that its returning current mode of lspcon.  Would you still prefer to 
> call it mode only ?

Yes, the fact that it's the current mode is pretty obvious.

> >> +{
> >> +  u8 data;
> >> +  int ret = 0;
> >> +
> >> +  if (!current_mode) {
> >> +  DRM_ERROR("NULL input\n");
> >> +  return -EINVAL;
> >> +  }
> 

Re: [Intel-gfx] [PATCH 07/15] drm/omap: Use per-plane rotation property

[Ville Syrjälä]

On Thu, Aug 11, 2016 at 02:32:44PM +0300, Tomi Valkeinen wrote:
> Hi,
> 
> On 22/07/16 16:43, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > The global mode_config.rotation_property is going away, switch over to
> > per-plane rotation_property.
> > 
> > Not sure I got the annoying crtc rotation_property handling right.
> > Might work, or migth not.
> 
> I think something is funny with this patch or the series. I fetched your
> branch, and with your series, it looks like the primary planes lose all
> their props. modetest says:
> 
> could not get plane 26 properties: Invalid argument
> could not get plane 30 properties: Invalid argument

Hmm. Weird. Is it really the get props ioctl that fails?

The first EINVAL I can spot there is
if (!obj->properties) {
  ret = -EINVAL;
  goto out_unref;
}
which definitely makes no sense since this is assigned
as plane->base.properties = >properties. So can't be that unless
we manage to clear the pointer somehow after the init.

The only other direct EINVAL I see there is if
 drm_object_property_get_value(obj->properties->properties[i])
fails to find the passed prop in the properties array. Which clearly
can't happen since we got it from the array in the first place. Also,
clearly that code is rather inefficient, perhaps someone should rewrite
it a bit.

Can't quite see how this could fail for the plane in other ways. But I
might be blind.

> 
> and
> 
> Planes:
> id  crtcfb  CRTC x,yx,y gamma size  possible
> crtcs
> 26  28  55  0,0 0,0 0   0x0001
>   formats: RG16 RX12 XR12 RA12 AR12 XR15 AR15 RG24 RX24 XR24 RA24 AR24
>   no properties found
> 30  0   0   0,0 0,0 0   0x0002
>   formats: RG16 RX12 XR12 RA12 AR12 XR15 AR15 RG24 RX24 XR24 RA24 AR24
> NV12 YUYV UYVY
>   no properties found
> 
> I didn't look closer yet.
> 
>  Tomi
> 




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

Re: [Intel-gfx] [PATCH 28/33] drm/i915: Move per-request pid from request to ctx

[Chris Wilson]

On Thu, Aug 11, 2016 at 03:32:18PM +0300, Joonas Lahtinen wrote:
> On su, 2016-08-07 at 15:45 +0100, Chris Wilson wrote:
> > Since contexts are not currently shared between userspace processes, we
> 
> How about future?

Don't care too much (not to the cost of tracking pid on every request)
if one process gives another process the entirety of its GPU memory and
state and then proceeds to go bang. The only situation I do care about
is passing an open render fd over AF_UNIX - and fortunately those always
use a context.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 25/33] drm/i915: Use VMA for wa_ctx tracking

[Joonas Lahtinen]

On to, 2016-08-11 at 12:02 +0100, Chris Wilson wrote:
> On Thu, Aug 11, 2016 at 01:53:40PM +0300, Joonas Lahtinen wrote:
> > 
> > On su, 2016-08-07 at 15:45 +0100, Chris Wilson wrote:
> > > 
> > > @@ -2019,9 +2023,9 @@ populate_lr_context(struct i915_gem_context *ctx,
> > >      RING_INDIRECT_CTX(engine->mmio_base), 0);
> > >   ASSIGN_CTX_REG(reg_state, CTX_RCS_INDIRECT_CTX_OFFSET,
> > >      RING_INDIRECT_CTX_OFFSET(engine->mmio_base), 0);
> > > - if (engine->wa_ctx.obj) {
> > > + if (engine->wa_ctx.vma) {
> > >   struct i915_ctx_workarounds *wa_ctx = >wa_ctx;
> > > - uint32_t ggtt_offset = 
> > > i915_gem_obj_ggtt_offset(wa_ctx->obj);
> > > + u32 ggtt_offset = wa_ctx->vma->node.start;
> > lower_32_bits()?
> I considered, I didn't to keep the changes to a minimum plus I've a
> slight unease about making it seem like we don't care about the upper 32
> bits.
> 
> static inline u32 i915_ggtt_offset(vma)
> {
>   GEM_BUG_ON(upper_32_bits(vma->node.start));
>   return lower_32_bits(vma->node.start);
> }
> 

I was about to suggest this, it could maybe even take u64, depending on
how the respective locations look after the VMA overhaul.

Regards, Joonas

> is possibly overkill but stops me feeling uneasy about the
> seeming truncation. Is this something that UBSAN detects?
> -Chris
> 
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 26/33] drm/i915: Track pinned VMA

[Chris Wilson]

On Thu, Aug 11, 2016 at 03:18:44PM +0300, Joonas Lahtinen wrote:
> On su, 2016-08-07 at 15:45 +0100, Chris Wilson wrote:
> > @@ -1616,7 +1618,7 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void 
> > *data,
> >  
> >  /**
> >   * i915_gem_fault - fault a page into the GTT
> > - * @vma: VMA in question
> > + * @mm: VMA in question
> 
> should be @vm or whatever the correct name.
> 
> >   * @vmf: fault info
> >   *
> >   * The fault handler is set up by drm_gem_mmap() when a object is GTT 
> > mapped
> > @@ -1630,20 +1632,21 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void 
> > *data,
> >   * suffer if the GTT working set is large or there are few fence registers
> >   * left.
> >   */
> > -int i915_gem_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
> > +int i915_gem_fault(struct vm_area_struct *vm, struct vm_fault *vmf)
> 
> 'vm' is used elsewhere for the address space, maybe 'kvma'? Or 'area'
> (used in linux/mm.h too occasionally)

I also was tempted by kvma. But area is better.

> 
> > @@ -1722,13 +1726,13 @@ int i915_gem_fault(struct vm_area_struct *vma, 
> > struct vm_fault *vmf)
> >     } else {
> >     if (!obj->fault_mappable) {
> >     unsigned long size = min_t(unsigned long,
> > -      vma->vm_end - vma->vm_start,
> > +      vm->vm_end - vm->vm_start,
> >        obj->base.size);
> >     int i;
> >  
> >     for (i = 0; i < size >> PAGE_SHIFT; i++) {
> > -   ret = vm_insert_pfn(vma,
> > -   (unsigned 
> > long)vma->vm_start + i * PAGE_SIZE,
> > +   ret = vm_insert_pfn(vm,
> > +   (unsigned long)vm->vm_start 
> > + i * PAGE_SIZE,
> 
> Hmm, vm->vm_start is already unsigned long, so cast could be
> eliminated.
> 
> >     pfn + i);
> >     if (ret)
> >     break;
> > @@ -1736,12 +1740,12 @@ int i915_gem_fault(struct vm_area_struct *vma, 
> > struct vm_fault *vmf)
> >  
> >     obj->fault_mappable = true;
> >     } else
> > -   ret = vm_insert_pfn(vma,
> > +   ret = vm_insert_pfn(vm,
> >     (unsigned long)vmf->virtual_address,
> >     pfn + page_offset);
> >     }
> >  err_unpin:
> > -   i915_gem_object_ggtt_unpin_view(obj, );
> > +   __i915_vma_unpin(vma);
> >  err_unlock:
> >     mutex_unlock(>struct_mutex);
> >  err_rpm:
> > @@ -3190,7 +3194,7 @@ i915_gem_object_set_to_gtt_domain(struct 
> > drm_i915_gem_object *obj, bool write)
> >     old_write_domain);
> >  
> >     /* And bump the LRU for this access */
> > -   vma = i915_gem_obj_to_ggtt(obj);
> > +   vma = i915_gem_object_to_ggtt(obj, NULL);
> >     if (vma &&
> >     drm_mm_node_allocated(>node) &&
> >     !i915_vma_is_active(vma))
> > @@ -3414,11 +3418,12 @@ rpm_put:
> >   * Can be called from an uninterruptible phase (modesetting) and allows
> >   * any flushes to be pipelined (for pageflips).
> >   */
> > -int
> > +struct i915_vma *
> >  i915_gem_object_pin_to_display_plane(struct drm_i915_gem_object *obj,
> >      u32 alignment,
> >      const struct i915_ggtt_view *view)
> >  {
> > +   struct i915_vma *vma;
> >     u32 old_read_domains, old_write_domain;
> >     int ret;
> >  
> > @@ -3438,19 +3443,23 @@ i915_gem_object_pin_to_display_plane(struct 
> > drm_i915_gem_object *obj,
> >      */
> >     ret = i915_gem_object_set_cache_level(obj,
> >       HAS_WT(obj->base.dev) ? 
> > I915_CACHE_WT : I915_CACHE_NONE);
> > -   if (ret)
> > +   if (ret) {
> > +   vma = ERR_PTR(ret);
> >     goto err_unpin_display;
> > +   }
> >  
> >     /* As the user may map the buffer once pinned in the display plane
> >      * (e.g. libkms for the bootup splash), we have to ensure that we
> >      * always use map_and_fenceable for all scanout buffers.
> >      */
> > -   ret = i915_gem_object_ggtt_pin(obj, view, 0, alignment,
> > +   vma = i915_gem_object_ggtt_pin(obj, view, 0, alignment,
> >        view->type == I915_GGTT_VIEW_NORMAL ?
> >        PIN_MAPPABLE : 0);
> > -   if (ret)
> > +   if (IS_ERR(vma))
> >     goto err_unpin_display;
> >  
> > +   WARN_ON(obj->pin_display > i915_vma_pin_count(vma));
> > +
> >     i915_gem_object_flush_cpu_write_domain(obj);
> >  
> >     old_write_domain = obj->base.write_domain;
> > @@ -3466,23 +3475,23 @@ i915_gem_object_pin_to_display_plane(struct 
> > drm_i915_gem_object *obj,
> >     old_read_domains,
> >     

Re: [Intel-gfx] [PATCH 29/33] drm/i915: Only record active and pending requests upon a GPU hang

[Joonas Lahtinen]

On su, 2016-08-07 at 15:45 +0100, Chris Wilson wrote:
> There is no other state pertaining to the completed requests in the
> hang, other than gleamed through the ringbuffer, so including the
> expired requests in the list of outstanding requests simply adds noise.
> 
> Signed-off-by: Chris Wilson 

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 28/33] drm/i915: Move per-request pid from request to ctx

[Joonas Lahtinen]

On su, 2016-08-07 at 15:45 +0100, Chris Wilson wrote:
> Since contexts are not currently shared between userspace processes, we

How about future?

Patch itself seems fine. Title could be more like "Move PID tracking
from request to context".

Regards, Joonas

> have an exact correspondence between context creator and guilty batch
> submitter. Therefore we can save some per-batch work by inspecting the
> context->pid upon error instead. Note that we take the context's
> creator's pid rather than the file's pid in order to better track fd
> passed over sockets.
> 
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 25 -
>  drivers/gpu/drm/i915/i915_drv.h |  2 ++
>  drivers/gpu/drm/i915/i915_gem_context.c |  4 
>  drivers/gpu/drm/i915/i915_gem_request.c |  5 -
>  drivers/gpu/drm/i915/i915_gem_request.h |  3 ---
>  drivers/gpu/drm/i915/i915_gpu_error.c   | 13 ++---
>  6 files changed, 32 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 5f00d6347905..963c6d28d332 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -460,6 +460,8 @@ static int i915_gem_object_info(struct seq_file *m, void* 
> data)
>   print_context_stats(m, dev_priv);
>   list_for_each_entry_reverse(file, >filelist, lhead) {
>   struct file_stats stats;
> + struct drm_i915_file_private *file_priv = file->driver_priv;
> + struct drm_i915_gem_request *request;
>   struct task_struct *task;
>  
>   memset(, 0, sizeof(stats));
> @@ -473,10 +475,17 @@ static int i915_gem_object_info(struct seq_file *m, 
> void* data)
>    * still alive (e.g. get_pid(current) => fork() => exit()).
>    * Therefore, we need to protect this ->comm access using RCU.
>    */
> + mutex_lock(>struct_mutex);
> + request = list_first_entry_or_null(_priv->mm.request_list,
> +    struct drm_i915_gem_request,
> +    client_list);
>   rcu_read_lock();
> - task = pid_task(file->pid, PIDTYPE_PID);
> + task = pid_task(request && request->ctx->pid ?
> + request->ctx->pid : file->pid,
> + PIDTYPE_PID);
>   print_file_stats(m, task ? task->comm : "", stats);
>   rcu_read_unlock();
> + mutex_unlock(>struct_mutex);
>   }
>   mutex_unlock(>filelist_mutex);
>  
> @@ -657,12 +666,11 @@ static int i915_gem_request_info(struct seq_file *m, 
> void *data)
>  
>   seq_printf(m, "%s requests: %d\n", engine->name, count);
>   list_for_each_entry(req, >request_list, link) {
> + struct pid *pid = req->ctx->pid;
>   struct task_struct *task;
>  
>   rcu_read_lock();
> - task = NULL;
> - if (req->pid)
> - task = pid_task(req->pid, PIDTYPE_PID);
> + task = pid ? pid_task(pid, PIDTYPE_PID) : NULL;
>   seq_printf(m, "%x @ %d: %s [%d]\n",
>      req->fence.seqno,
>      (int) (jiffies - req->emitted_jiffies),
> @@ -1951,18 +1959,17 @@ static int i915_context_status(struct seq_file *m, 
> void *unused)
>  
>   list_for_each_entry(ctx, _priv->context_list, link) {
>   seq_printf(m, "HW context %u ", ctx->hw_id);
> - if (IS_ERR(ctx->file_priv)) {
> - seq_puts(m, "(deleted) ");
> - } else if (ctx->file_priv) {
> - struct pid *pid = ctx->file_priv->file->pid;
> + if (ctx->pid) {
>   struct task_struct *task;
>  
> - task = get_pid_task(pid, PIDTYPE_PID);
> + task = get_pid_task(ctx->pid, PIDTYPE_PID);
>   if (task) {
>   seq_printf(m, "(%s [%d]) ",
>      task->comm, task->pid);
>   put_task_struct(task);
>   }
> + } else if (IS_ERR(ctx->file_priv)) {
> + seq_puts(m, "(deleted) ");
>   } else {
>   seq_puts(m, "(kernel) ");
>   }
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 4023718017a8..e7357656728e 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -560,6 +560,7 @@ struct drm_i915_error_state {
>  
>   struct drm_i915_error_request {
>   long jiffies;
> + pid_t pid;
>   u32 

Re: [Intel-gfx] [PATCH 26/33] drm/i915: Track pinned VMA

[Joonas Lahtinen]

On su, 2016-08-07 at 15:45 +0100, Chris Wilson wrote:
> @@ -1616,7 +1618,7 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
>  
>  /**
>   * i915_gem_fault - fault a page into the GTT
> - * @vma: VMA in question
> + * @mm: VMA in question

should be @vm or whatever the correct name.

>   * @vmf: fault info
>   *
>   * The fault handler is set up by drm_gem_mmap() when a object is GTT mapped
> @@ -1630,20 +1632,21 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void 
> *data,
>   * suffer if the GTT working set is large or there are few fence registers
>   * left.
>   */
> -int i915_gem_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
> +int i915_gem_fault(struct vm_area_struct *vm, struct vm_fault *vmf)

'vm' is used elsewhere for the address space, maybe 'kvma'? Or 'area'
(used in linux/mm.h too occasionally)

> @@ -1722,13 +1726,13 @@ int i915_gem_fault(struct vm_area_struct *vma, struct 
> vm_fault *vmf)
>   } else {
>   if (!obj->fault_mappable) {
>   unsigned long size = min_t(unsigned long,
> -    vma->vm_end - vma->vm_start,
> +    vm->vm_end - vm->vm_start,
>      obj->base.size);
>   int i;
>  
>   for (i = 0; i < size >> PAGE_SHIFT; i++) {
> - ret = vm_insert_pfn(vma,
> - (unsigned 
> long)vma->vm_start + i * PAGE_SIZE,
> + ret = vm_insert_pfn(vm,
> + (unsigned long)vm->vm_start 
> + i * PAGE_SIZE,

Hmm, vm->vm_start is already unsigned long, so cast could be
eliminated.

>   pfn + i);
>   if (ret)
>   break;
> @@ -1736,12 +1740,12 @@ int i915_gem_fault(struct vm_area_struct *vma, struct 
> vm_fault *vmf)
>  
>   obj->fault_mappable = true;
>   } else
> - ret = vm_insert_pfn(vma,
> + ret = vm_insert_pfn(vm,
>   (unsigned long)vmf->virtual_address,
>   pfn + page_offset);
>   }
>  err_unpin:
> - i915_gem_object_ggtt_unpin_view(obj, );
> + __i915_vma_unpin(vma);
>  err_unlock:
>   mutex_unlock(>struct_mutex);
>  err_rpm:
> @@ -3190,7 +3194,7 @@ i915_gem_object_set_to_gtt_domain(struct 
> drm_i915_gem_object *obj, bool write)
>   old_write_domain);
>  
>   /* And bump the LRU for this access */
> - vma = i915_gem_obj_to_ggtt(obj);
> + vma = i915_gem_object_to_ggtt(obj, NULL);
>   if (vma &&
>   drm_mm_node_allocated(>node) &&
>   !i915_vma_is_active(vma))
> @@ -3414,11 +3418,12 @@ rpm_put:
>   * Can be called from an uninterruptible phase (modesetting) and allows
>   * any flushes to be pipelined (for pageflips).
>   */
> -int
> +struct i915_vma *
>  i915_gem_object_pin_to_display_plane(struct drm_i915_gem_object *obj,
>    u32 alignment,
>    const struct i915_ggtt_view *view)
>  {
> + struct i915_vma *vma;
>   u32 old_read_domains, old_write_domain;
>   int ret;
>  
> @@ -3438,19 +3443,23 @@ i915_gem_object_pin_to_display_plane(struct 
> drm_i915_gem_object *obj,
>    */
>   ret = i915_gem_object_set_cache_level(obj,
>     HAS_WT(obj->base.dev) ? 
> I915_CACHE_WT : I915_CACHE_NONE);
> - if (ret)
> + if (ret) {
> + vma = ERR_PTR(ret);
>   goto err_unpin_display;
> + }
>  
>   /* As the user may map the buffer once pinned in the display plane
>    * (e.g. libkms for the bootup splash), we have to ensure that we
>    * always use map_and_fenceable for all scanout buffers.
>    */
> - ret = i915_gem_object_ggtt_pin(obj, view, 0, alignment,
> + vma = i915_gem_object_ggtt_pin(obj, view, 0, alignment,
>      view->type == I915_GGTT_VIEW_NORMAL ?
>      PIN_MAPPABLE : 0);
> - if (ret)
> + if (IS_ERR(vma))
>   goto err_unpin_display;
>  
> + WARN_ON(obj->pin_display > i915_vma_pin_count(vma));
> +
>   i915_gem_object_flush_cpu_write_domain(obj);
>  
>   old_write_domain = obj->base.write_domain;
> @@ -3466,23 +3475,23 @@ i915_gem_object_pin_to_display_plane(struct 
> drm_i915_gem_object *obj,
>   old_read_domains,
>   old_write_domain);
>  
> - return 0;
> + return vma;
>  
>  err_unpin_display:
>   obj->pin_display--;
> - return ret;
> + return vma;
>  }
>  
>  void
> -i915_gem_object_unpin_from_display_plane(struct 

Re: [Intel-gfx] [PATCH v7 3/5] drm/i915: Check pixel rate for DP to VGA dongle

[Mika Kahola]

On Thu, 2016-08-11 at 12:56 +0200, Daniel Vetter wrote:
> On Thu, Aug 11, 2016 at 01:51:42PM +0300, Ville Syrjälä wrote:
> > On Thu, Aug 11, 2016 at 12:43:39PM +0300, Mika Kahola wrote:
> > > On Thu, 2016-08-11 at 10:18 +0300, Ville Syrjälä wrote:
> > > > On Mon, Aug 08, 2016 at 04:00:28PM +0300, Mika Kahola wrote:
> > > > > Filter out a mode that exceeds the max pixel rate setting
> > > > > for DP to VGA dongle. This is defined in DPCD register 0x81
> > > > > if detailed cap info i.e. info field is 4 bytes long and
> > > > > it is available for DP downstream port.
> > > > > 
> > > > > The register defines the pixel rate divided by 8 in MP/s.
> > > > > 
> > > > > v2: DPCD read outs and computation moved to drm (Ville, Daniel)
> > > > > v3: Sink pixel rate computation moved to drm_dp_max_sink_dotclock()
> > > > > function (Daniel)
> > > > > v4: Use of drm_dp_helper.c routines to compute max pixel clock (Ville)
> > > > > v5: Use of intel_dp->downstream_ports to read out port capabilities.
> > > > > Code restructuring (Ville)
> > > > > v6: Move DP branch device check to drm_dp_helper.c (Daniel)
> > > > > 
> > > > > Signed-off-by: Mika Kahola 
> > > > > ---
> > > > >  drivers/gpu/drm/i915/intel_dp.c | 25 -
> > > > >  1 file changed, 24 insertions(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > > index 21b04c3..e990c8b 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > > @@ -190,6 +190,26 @@ intel_dp_max_data_rate(int max_link_clock, int 
> > > > > max_lanes)
> > > > >   return (max_link_clock * max_lanes * 8) / 10;
> > > > >  }
> > > > >  
> > > > > +static int
> > > > > +intel_dp_downstream_max_dotclock(struct intel_dp *intel_dp, int 
> > > > > dotclk)
> > > > > +{
> > > > 
> > > > I would just
> > > > 
> > > > {
> > > > int max_dotclk = dev_priv->max_dotclk_freq;
> > > > 
> > > > ds_max_dotclk = ...;
> > > > if (ds_dotclk != 0)
> > > > max_dotclk = min(max_dotclk, ds_max_dotclk);
> > > > 
> > > > return max_dotclk;
> > > > }
> > > > 
> > > > > + int ds_dotclk;
> > > > > + int type;
> > > > > +
> > > > > + ds_dotclk = drm_dp_downstream_max_clock(intel_dp->dpcd,
> > > > > + 
> > > > > intel_dp->downstream_ports);
> > > > > +
> > > > > + if (ds_dotclk == 0)
> > > > > + return dotclk;
> > > > > +
> > > > > + type = intel_dp->downstream_ports[0] & DP_DS_PORT_TYPE_MASK;
> > > > > + 
> > > > > + if (type != DP_DS_PORT_TYPE_VGA)
> > > > > + return dotclk;
> > > > 
> > > > Why isn't drm_dp_downstream_max_clock() handling all of it already?
> > > > Why are we even checking for !=VGA?
> > > The routine drm_dp_downstream_max_clock returns the clock rate which can
> > > be dotclock (VGA only) or TMDS clock (for DVI, HDMI, DP++). Here, we
> > > need to have a check for this as we are only interested to update VGA
> > > dotclock value.
> > 
> > We should handle it all. Actually I'm not even sure how we're supposed
> > to deal with the downstream port max TMDS clock since for HDMI that
> > depends on the bpc, but since this is about a DP->HDMI conversion, I
> > don't know if we have to take the downstream port max TMDS clock into
> > account when choosing the bpc over the DP link as well. I suppose that's
> > possible if the dongle can't change change the bpc, and instead just
> > passes things through. I think this is one of those places where the
> > DP spec is way too unclear. But for DP->VGA there is no clock going out
> > the other end, so it must be just about the limits of the DP input or
> > the DAC.
> 
> I guess we should defensively assume that the tmds clock limit is both for
> the input and the output signal, worst case, for the dp->hdmi dongle?
> Except when it's a passive level-shifter only one ofc.
> -Daniel
So, we should respect dongles both tmds and bpc values. I thought that
tmds clock checks was already covered by Ville's DP dual mode patch
series?


-- 
Mika Kahola - Intel OTC

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

Re: [Intel-gfx] [PATCH 27/33] drm/i915: Print the batchbuffer offset next to BBADDR in error state

[Joonas Lahtinen]

On su, 2016-08-07 at 15:45 +0100, Chris Wilson wrote:
> It is useful when looking at captured error states to check the recorded
> BBADDR register (the address of the last batchbuffer instruction loaded)
> against the expected offset of the batch buffer, and so do a quick check
> that (a) the capture is true or (b) HEAD hasn't wandered off into the
> badlands.
> 
> Signed-off-by: Chris Wilson 

Reviewed-by: Joonas Lahtinen 

> ---
>  drivers/gpu/drm/i915/i915_drv.h   |  1 +
>  drivers/gpu/drm/i915/i915_gpu_error.c | 13 -
>  2 files changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index ed9d872859b3..4023718017a8 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -552,6 +552,7 @@ struct drm_i915_error_state {
>   struct drm_i915_error_object {
>   int page_count;
>   u64 gtt_offset;
> + u64 gtt_size;
>   u32 *pages[0];
>   } *ringbuffer, *batchbuffer, *wa_batchbuffer, *ctx, *hws_page;
>  
> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
> b/drivers/gpu/drm/i915/i915_gpu_error.c
> index 1bceaf96bc5f..9faac19029cd 100644
> --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> @@ -243,6 +243,14 @@ static void error_print_engine(struct 
> drm_i915_error_state_buf *m,
>   err_printf(m, "  IPEIR: 0x%08x\n", ee->ipeir);
>   err_printf(m, "  IPEHR: 0x%08x\n", ee->ipehr);
>   err_printf(m, "  INSTDONE: 0x%08x\n", ee->instdone);
> + if (ee->batchbuffer) {
> + u64 start = ee->batchbuffer->gtt_offset;
> + u64 end = start + ee->batchbuffer->gtt_size;
> +
> + err_printf(m, "  batch: [0x%08x %08x, 0x%08x %08x]\n",

underscores to join the numbers for consistency, I think one way or
another should be kept as a standard.

> +    upper_32_bits(start), lower_32_bits(start),
> +    upper_32_bits(end), lower_32_bits(end));
> + }
>   if (INTEL_GEN(m->i915) >= 4) {
>   err_printf(m, "  BBADDR: 0x%08x %08x\n",
>      (u32)(ee->bbaddr>>32), (u32)ee->bbaddr);
> @@ -657,7 +665,10 @@ i915_error_object_create(struct drm_i915_private 
> *dev_priv,
>   if (!dst)
>   return NULL;
>  
> - reloc_offset = dst->gtt_offset = vma->node.start;
> + dst->gtt_offset = vma->node.start;
> + dst->gtt_size = vma->node.size;
> +
> + reloc_offset = dst->gtt_offset;
>   use_ggtt = (src->cache_level == I915_CACHE_NONE &&
>      (vma->flags & I915_VMA_GLOBAL_BIND) &&
>      reloc_offset + num_pages * PAGE_SIZE <= ggtt->mappable_end);
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Ro.CI.BAT: failure for Reclassify messages from GuC loader/submission (rev2)

[Patchwork]

== Series Details ==

Series: Reclassify messages from GuC loader/submission (rev2)
URL   : https://patchwork.freedesktop.org/series/10918/
State : failure

== Summary ==

Applying: drm: extra printk() wrapper macros
Applying: drm/i915/guc: downgrade some DRM_ERROR() messages to DRM_WARN()
Applying: drm/i915/guc: revisit GuC loader message levels
Applying: NOMERGE: next version of GuC firmware is 8.11
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/intel_guc_loader.c
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/intel_guc_loader.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_guc_loader.c
error: Failed to merge in the changes.
Patch failed at 0004 NOMERGE: next version of GuC firmware is 8.11
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

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

[Intel-gfx] ✗ Ro.CI.BAT: failure for Shrink and lock the size static gen6 semaphore init array (rev2)

[Patchwork]

== Series Details ==

Series: Shrink and lock the size static gen6 semaphore init array (rev2)
URL   : https://patchwork.freedesktop.org/series/10949/
State : failure

== Summary ==

Series 10949v2 Shrink and lock the size static gen6 semaphore init array
http://patchwork.freedesktop.org/api/1.0/series/10949/revisions/2/mbox

Test gem_exec_suspend:
Subgroup basic-s3:
incomplete -> DMESG-WARN (fi-skl-i7-6700k)
Test kms_cursor_legacy:
Subgroup basic-flip-vs-cursor-legacy:
fail   -> PASS   (ro-hsw-i7-4770r)
fail   -> PASS   (ro-byt-n2820)
pass   -> FAIL   (ro-bdw-i5-5250u)
Subgroup basic-flip-vs-cursor-varying-size:
pass   -> FAIL   (ro-hsw-i7-4770r)
pass   -> FAIL   (ro-byt-n2820)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> SKIP   (ro-bdw-i5-5250u)
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (ro-bdw-i7-5600u)

fi-hsw-i7-4770k  total:244  pass:221  dwarn:0   dfail:0   fail:1   skip:22 
fi-kbl-qkkr  total:244  pass:186  dwarn:28  dfail:0   fail:3   skip:27 
fi-skl-i5-6260u  total:244  pass:224  dwarn:4   dfail:0   fail:2   skip:14 
fi-skl-i7-6700k  total:244  pass:208  dwarn:4   dfail:2   fail:2   skip:28 
fi-snb-i7-2600   total:244  pass:202  dwarn:0   dfail:0   fail:0   skip:42 
ro-bdw-i5-5250u  total:240  pass:218  dwarn:3   dfail:0   fail:2   skip:17 
ro-bdw-i7-5600u  total:240  pass:206  dwarn:1   dfail:0   fail:1   skip:32 
ro-bsw-n3050 total:240  pass:195  dwarn:0   dfail:0   fail:3   skip:42 
ro-byt-n2820 total:240  pass:198  dwarn:0   dfail:0   fail:2   skip:40 
ro-hsw-i3-4010u  total:240  pass:214  dwarn:0   dfail:0   fail:0   skip:26 
ro-hsw-i7-4770r  total:240  pass:213  dwarn:0   dfail:0   fail:1   skip:26 
ro-ilk1-i5-650   total:235  pass:173  dwarn:0   dfail:0   fail:2   skip:60 
ro-ivb-i7-3770   total:240  pass:205  dwarn:0   dfail:0   fail:0   skip:35 
ro-ivb2-i7-3770  total:240  pass:209  dwarn:0   dfail:0   fail:0   skip:31 
ro-skl3-i5-6260u total:240  pass:222  dwarn:0   dfail:0   fail:4   skip:14 
ro-bdw-i7-5557U failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1836/

3c6050a drm-intel-nightly: 2016y-08m-11d-10h-34m-38s UTC integration manifest
547ec16 drm/i915: Initialize legacy semaphores from engine hw id indexed array
b2f8c29 drm/i915: Add enum for hardware engine identifiers

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

Re: [Intel-gfx] [PATCH 07/15] drm/omap: Use per-plane rotation property

[Tomi Valkeinen]

Hi,

On 22/07/16 16:43, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> The global mode_config.rotation_property is going away, switch over to
> per-plane rotation_property.
> 
> Not sure I got the annoying crtc rotation_property handling right.
> Might work, or migth not.

I think something is funny with this patch or the series. I fetched your
branch, and with your series, it looks like the primary planes lose all
their props. modetest says:

could not get plane 26 properties: Invalid argument
could not get plane 30 properties: Invalid argument

and

Planes:
id  crtcfb  CRTC x,yx,y gamma size  possible
crtcs
26  28  55  0,0 0,0 0   0x0001
  formats: RG16 RX12 XR12 RA12 AR12 XR15 AR15 RG24 RX24 XR24 RA24 AR24
  no properties found
30  0   0   0,0 0,0 0   0x0002
  formats: RG16 RX12 XR12 RA12 AR12 XR15 AR15 RG24 RX24 XR24 RA24 AR24
NV12 YUYV UYVY
  no properties found

I didn't look closer yet.

 Tomi



signature.asc
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [1/2] Revert "drm/fb-helper: Reduce READ_ONCE(master) to lockless_dereference"

[Patchwork]

== Series Details ==

Series: series starting with [1/2] Revert "drm/fb-helper: Reduce 
READ_ONCE(master) to lockless_dereference"
URL   : https://patchwork.freedesktop.org/series/10948/
State : failure

== Summary ==

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

Test gem_exec_suspend:
Subgroup basic-s3:
incomplete -> DMESG-WARN (fi-skl-i7-6700k)
Test kms_cursor_legacy:
Subgroup basic-flip-vs-cursor-legacy:
fail   -> PASS   (ro-hsw-i7-4770r)
fail   -> PASS   (ro-byt-n2820)
pass   -> FAIL   (fi-hsw-i7-4770k)
Subgroup basic-flip-vs-cursor-varying-size:
fail   -> PASS   (fi-hsw-i7-4770k)
fail   -> PASS   (ro-bdw-i5-5250u)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> SKIP   (ro-bdw-i5-5250u)
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> SKIP   (ro-bdw-i7-5557U)
dmesg-warn -> SKIP   (ro-bdw-i5-5250u)
Subgroup suspend-read-crc-pipe-c:
dmesg-warn -> SKIP   (ro-bdw-i5-5250u)

fi-hsw-i7-4770k  total:244  pass:221  dwarn:0   dfail:0   fail:1   skip:22 
fi-kbl-qkkr  total:244  pass:185  dwarn:30  dfail:1   fail:1   skip:27 
fi-skl-i5-6260u  total:244  pass:224  dwarn:4   dfail:0   fail:2   skip:14 
fi-skl-i7-6700k  total:244  pass:208  dwarn:4   dfail:2   fail:2   skip:28 
fi-snb-i7-2600   total:244  pass:202  dwarn:0   dfail:0   fail:0   skip:42 
ro-bdw-i5-5250u  total:240  pass:220  dwarn:1   dfail:0   fail:0   skip:19 
ro-bdw-i7-5557U  total:240  pass:220  dwarn:1   dfail:0   fail:0   skip:19 
ro-bdw-i7-5600u  total:240  pass:207  dwarn:0   dfail:0   fail:1   skip:32 
ro-bsw-n3050 total:240  pass:194  dwarn:0   dfail:0   fail:4   skip:42 
ro-byt-n2820 total:240  pass:199  dwarn:0   dfail:0   fail:1   skip:40 
ro-hsw-i3-4010u  total:240  pass:214  dwarn:0   dfail:0   fail:0   skip:26 
ro-hsw-i7-4770r  total:240  pass:214  dwarn:0   dfail:0   fail:0   skip:26 
ro-ilk1-i5-650   total:235  pass:173  dwarn:0   dfail:0   fail:2   skip:60 
ro-ivb-i7-3770   total:240  pass:205  dwarn:0   dfail:0   fail:0   skip:35 
ro-ivb2-i7-3770  total:240  pass:209  dwarn:0   dfail:0   fail:0   skip:31 
ro-skl3-i5-6260u total:240  pass:222  dwarn:0   dfail:0   fail:4   skip:14 

Results at /archive/results/CI_IGT_test/RO_Patchwork_1835/

3c6050a drm-intel-nightly: 2016y-08m-11d-10h-34m-38s UTC integration manifest
8ff8d08 locking/barriers: suppress sparse warnings in lockless_dereference()
fcc9432 Revert "drm/fb-helper: Reduce READ_ONCE(master) to lockless_dereference"

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

Re: [Intel-gfx] [PATCH v2] drm/i915: Initialize legacy semaphores from engine hw id indexed array

[Chris Wilson]

On Thu, Aug 11, 2016 at 12:05:58PM +0100, Tvrtko Ursulin wrote:
> @@ -1394,9 +1393,13 @@ static int gen6_signal(struct drm_i915_gem_request 
> *req)
>   if (ret)
>   return ret;
>  
> - for_each_engine_id(useless, dev_priv, id) {
> - i915_reg_t mbox_reg = req->engine->semaphore.mbox.signal[id];
> + for_each_engine(engine, dev_priv) {
> + i915_reg_t mbox_reg;
> +
> + if (engine->hw_id > GEN6_SEMAPHORE_LAST)
> + continue;

Yeah, this makes more sense to me...

> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
> b/drivers/gpu/drm/i915/intel_ringbuffer.h
> index ac568808aeb1..c2d8677b5b9f 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.h
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
> @@ -277,11 +277,12 @@ struct intel_engine_cs {
>   u32 sync_seqno[I915_NUM_ENGINES-1];
>  
>   union {
> +#define GEN6_SEMAPHORE_LAST VECS_HW
>   struct {
>   /* our mbox written by others */
> - u32 wait[I915_NUM_ENGINES];
> + u32 wait[GEN6_SEMAPHORE_LAST + 1];

but I agree with your hesistation here.

#define GEN6_SEMAPHORE_LAST VECS_HW
#define GEN6_NUM_SEMAPHORES (GEN6_SEMAPHORE_LAST_HW + 1)
#define GEN6_MASK_SEMAPHORES GENMASK(GEN6_SEMAPHORE_LAST, 0)

if (!(BIT(engine->hw_id) & GEN6_SEMAPHORES_MASK))
continue;

(can't decide on NUM/MASK_SEM or SEM_COUNT/MASK)

would that look better?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/kbl: Limit WaDisableDynamicCreditSharing to A0

[Matthew Auld]

But in the bug report the pciid=0x5916 and rev=0x0, which makes it KBL
A0, right? So something else must be going on here. There also seems
to be a mismatch between #2226938, #2225763 and #2225601 in terms of
what the wa should be, some make reference to bit[30].
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v4 3/4] drm/i915/guc: revisit GuC loader message levels

[Dave Gordon]

Some downgraded from DRM_ERROR() to DRM_WARN() or DRM_NOTE(),
a few upgraded from DRM_INFO() to DRM_NOTE() or DRM_WARN(),
and one eliminated completely.

v2: different permutation of levels :)
v3: convert a couple of "this shouldn't happen" messages to WARN()

Signed-off-by: Dave Gordon 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_guc_loader.c | 34 -
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 3763e30..d9cbc26 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -140,12 +140,14 @@ static u32 get_gttype(struct drm_i915_private *dev_priv)
 
 static u32 get_core_family(struct drm_i915_private *dev_priv)
 {
-   switch (INTEL_INFO(dev_priv)->gen) {
+   u32 gen = INTEL_GEN(dev_priv);
+
+   switch (gen) {
case 9:
return GFXCORE_FAMILY_GEN9;
 
default:
-   DRM_ERROR("GUC: unsupported core family\n");
+   WARN(1, "GEN%d does not support GuC operation!\n", gen);
return GFXCORE_FAMILY_UNKNOWN;
}
 }
@@ -435,7 +437,7 @@ int intel_guc_setup(struct drm_device *dev)
goto fail;
} else if (*fw_path == '\0') {
/* Device has a GuC but we don't know what f/w to load? */
-   DRM_INFO("No GuC firmware known for this platform\n");
+   WARN(1, "No GuC firmware known for this platform!\n");
err = -ENODEV;
goto fail;
}
@@ -473,10 +475,8 @@ int intel_guc_setup(struct drm_device *dev)
 * that the state and timing are fairly predictable
 */
err = i915_reset_guc(dev_priv);
-   if (err) {
-   DRM_ERROR("GuC reset failed: %d\n", err);
+   if (err)
goto fail;
-   }
 
err = guc_ucode_xfer(dev_priv);
if (!err)
@@ -534,15 +534,15 @@ int intel_guc_setup(struct drm_device *dev)
else if (err == 0)
DRM_INFO("GuC firmware load skipped\n");
else if (ret != -EIO)
-   DRM_INFO("GuC firmware load failed: %d\n", err);
+   DRM_NOTE("GuC firmware load failed: %d\n", err);
else
-   DRM_ERROR("GuC firmware load failed: %d\n", err);
+   DRM_WARN("GuC firmware load failed: %d\n", err);
 
if (i915.enable_guc_submission) {
if (fw_path == NULL)
DRM_INFO("GuC submission without firmware not 
supported\n");
if (ret == 0)
-   DRM_INFO("Falling back from GuC submission to execlist 
mode\n");
+   DRM_NOTE("Falling back from GuC submission to execlist 
mode\n");
else
DRM_ERROR("GuC init failed: %d\n", ret);
}
@@ -573,7 +573,7 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
intel_guc_fw *guc_fw)
 
/* Check the size of the blob before examining buffer contents */
if (fw->size < sizeof(struct guc_css_header)) {
-   DRM_ERROR("Firmware header is missing\n");
+   DRM_NOTE("Firmware header is missing\n");
goto fail;
}
 
@@ -585,7 +585,7 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
intel_guc_fw *guc_fw)
css->key_size_dw - css->exponent_size_dw) * sizeof(u32);
 
if (guc_fw->header_size != sizeof(struct guc_css_header)) {
-   DRM_ERROR("CSS header definition mismatch\n");
+   DRM_NOTE("CSS header definition mismatch\n");
goto fail;
}
 
@@ -595,7 +595,7 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
intel_guc_fw *guc_fw)
 
/* now RSA */
if (css->key_size_dw != UOS_RSA_SCRATCH_MAX_COUNT) {
-   DRM_ERROR("RSA key size is bad\n");
+   DRM_NOTE("RSA key size is bad\n");
goto fail;
}
guc_fw->rsa_offset = guc_fw->ucode_offset + guc_fw->ucode_size;
@@ -604,14 +604,14 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
intel_guc_fw *guc_fw)
/* At least, it should have header, uCode and RSA. Size of all three. */
size = guc_fw->header_size + guc_fw->ucode_size + guc_fw->rsa_size;
if (fw->size < size) {
-   DRM_ERROR("Missing firmware components\n");
+   DRM_NOTE("Missing firmware components\n");
goto fail;
}
 
/* Header and uCode will be loaded to WOPCM. Size of the two. */
size = guc_fw->header_size + guc_fw->ucode_size;
if (size > guc_wopcm_size(to_i915(dev))) {
-   DRM_ERROR("Firmware is too large to fit in WOPCM\n");
+   DRM_NOTE("Firmware is too large to fit in WOPCM\n");

[Intel-gfx] [PATCH v4 4/4] NOMERGE: next version of GuC firmware is 8.11

[Dave Gordon]

Update GuC firmware version to 8.11, and re-enable GuC loading and
submission by default on suitable platforms, since it's Intel's
Plan of Record that GuC submission shall be used where available.

Signed-off-by: Dave Gordon 
---
 drivers/gpu/drm/i915/i915_params.c  | 4 ++--
 drivers/gpu/drm/i915/intel_guc_loader.c | 7 +++
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 768ad89..02419a6 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -55,8 +55,8 @@ struct i915_params i915 __read_mostly = {
.verbose_state_checks = 1,
.nuclear_pageflip = 0,
.edp_vswing = 0,
-   .enable_guc_loading = 0,
-   .enable_guc_submission = 0,
+   .enable_guc_loading = -1,
+   .enable_guc_submission = -1,
.guc_log_level = -1,
.enable_dp_mst = true,
.inject_load_failure = 0,
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index d9cbc26..de8b8cd 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -62,6 +62,9 @@
 #define I915_SKL_GUC_UCODE "i915/skl_guc_ver6_1.bin"
 MODULE_FIRMWARE(I915_SKL_GUC_UCODE);
 
+#define I915_SKL_GUC_UCODE_NEXT "i915/skl_guc_ver8.bin"
+MODULE_FIRMWARE(I915_SKL_GUC_UCODE_NEXT);
+
 #define I915_BXT_GUC_UCODE "i915/bxt_guc_ver8_7.bin"
 MODULE_FIRMWARE(I915_BXT_GUC_UCODE);
 
@@ -696,6 +699,10 @@ void intel_guc_init(struct drm_device *dev)
if (!HAS_GUC_UCODE(dev)) {
fw_path = NULL;
} else if (IS_SKYLAKE(dev)) {
+   fw_path = I915_SKL_GUC_UCODE_NEXT;
+   guc_fw->guc_fw_major_wanted = 8;
+   guc_fw->guc_fw_minor_wanted = 11;
+   } else if (IS_SKYLAKE(dev)) {
fw_path = I915_SKL_GUC_UCODE;
guc_fw->guc_fw_major_wanted = 6;
guc_fw->guc_fw_minor_wanted = 1;
-- 
1.9.1

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

[Intel-gfx] [PATCH v4 1/4] drm: extra printk() wrapper macros

[Dave Gordon]

We had only DRM_INFO() and DRM_ERROR(), whereas the underlying printk()
provides several other useful intermediate levels such as NOTICE and
WARNING. So this patch fills out the set by providing both regular and
once-only macros for each of the levels INFO, NOTICE, and WARNING, using
a common underlying macro that does all the token-pasting.

DRM_ERROR is unchanged, as it's not just a printk wrapper.

v2:
Fix whitespace, missing ## (Eric Engestrom)

Signed-off-by: Dave Gordon 
Reviewed-by: Eric Engestrom 
Cc: dri-de...@lists.freedesktop.org
---
 include/drm/drmP.h | 26 --
 1 file changed, 20 insertions(+), 6 deletions(-)

diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 856c174..c9f168a 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -163,6 +163,26 @@ void drm_err(const char *format, ...);
 /** \name Macros to make printk easier */
 /*@{*/
 
+#define _DRM_PRINTK(once, level, fmt, ...) \
+   do {\
+   printk##once(KERN_##level "[" DRM_NAME "] " fmt,\
+##__VA_ARGS__);\
+   } while (0)
+
+#define DRM_INFO(fmt, ...) \
+   _DRM_PRINTK(, INFO, fmt, ##__VA_ARGS__)
+#define DRM_NOTE(fmt, ...) \
+   _DRM_PRINTK(, NOTICE, fmt, ##__VA_ARGS__)
+#define DRM_WARN(fmt, ...) \
+   _DRM_PRINTK(, WARNING, fmt, ##__VA_ARGS__)
+
+#define DRM_INFO_ONCE(fmt, ...)
\
+   _DRM_PRINTK(_once, INFO, fmt, ##__VA_ARGS__)
+#define DRM_NOTE_ONCE(fmt, ...)
\
+   _DRM_PRINTK(_once, NOTICE, fmt, ##__VA_ARGS__)
+#define DRM_WARN_ONCE(fmt, ...)
\
+   _DRM_PRINTK(_once, WARNING, fmt, ##__VA_ARGS__)
+
 /**
  * Error output.
  *
@@ -188,12 +208,6 @@ void drm_err(const char *format, ...);
drm_err(fmt, ##__VA_ARGS__);\
 })
 
-#define DRM_INFO(fmt, ...) \
-   printk(KERN_INFO "[" DRM_NAME "] " fmt, ##__VA_ARGS__)
-
-#define DRM_INFO_ONCE(fmt, ...)\
-   printk_once(KERN_INFO "[" DRM_NAME "] " fmt, ##__VA_ARGS__)
-
 /**
  * Debug output.
  *
-- 
1.9.1

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

[Intel-gfx] [PATCH v4 0/4] Reclassify messages from GuC loader/submission

[Dave Gordon]

Various downgrading, upgrading, or general reorganisation of the
messages emitted by the GuC code. Mostly:
* "can't happen" cases (inconsistencies/misconfiguration) are ERRORs
* recoverable (ignored) errors are downgraded to WARNINGs
* important auxiliary messages about failure or mode change are NOTICEs
* anything else (messages for developer rather than sysadmin) is DEBUG

v4:
  Resend with added cover letter 

Dave Gordon (4):
  drm: extra printk() wrapper macros
  drm/i915/guc: downgrade some DRM_ERROR() messages to DRM_WARN()
  drm/i915/guc: revisit GuC loader message levels
  drm/i915/guc: next version of GuC firmware is 8.11

 drivers/gpu/drm/i915/i915_guc_submission.c | 18 +
 drivers/gpu/drm/i915/i915_params.c |  4 +--
 drivers/gpu/drm/i915/intel_guc_loader.c| 41 +-
 include/drm/drmP.h | 26 ++-
 4 files changed, 53 insertions(+), 36 deletions(-)

-- 
1.9.1

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

[Intel-gfx] [PATCH v4 2/4] drm/i915/guc: downgrade some DRM_ERROR() messages to DRM_WARN()

[Dave Gordon]

Where we're going to continue regardless of the problem, rather than
fail, then the message should be a WARNing rather than an ERROR.

Signed-off-by: Dave Gordon 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 18 +++---
 1 file changed, 7 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 6831321..d43625f 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -114,10 +114,8 @@ static int host2guc_action(struct intel_guc *guc, u32 
*data, u32 len)
if (ret != -ETIMEDOUT)
ret = -EIO;
 
-   DRM_ERROR("GUC: host2guc action 0x%X failed. ret=%d "
-   "status=0x%08X response=0x%08X\n",
-   data[0], ret, status,
-   I915_READ(SOFT_SCRATCH(15)));
+   DRM_WARN("Action 0x%X failed; ret=%d status=0x%08X 
response=0x%08X\n",
+data[0], ret, status, I915_READ(SOFT_SCRATCH(15)));
 
dev_priv->guc.action_fail += 1;
dev_priv->guc.action_err = ret;
@@ -556,8 +554,8 @@ static int guc_ring_doorbell(struct i915_guc_client *gc)
if (db_ret.db_status == GUC_DOORBELL_DISABLED)
break;
 
-   DRM_ERROR("Cookie mismatch. Expected %d, returned %d\n",
- db_cmp.cookie, db_ret.cookie);
+   DRM_WARN("Cookie mismatch. Expected %d, found %d\n",
+db_cmp.cookie, db_ret.cookie);
 
/* update the cookie to newly read cookie from GuC */
db_cmp.cookie = db_ret.cookie;
@@ -745,8 +743,8 @@ static void guc_init_doorbell_hw(struct intel_guc *guc)
/* Restore to original value */
err = guc_update_doorbell_id(guc, client, db_id);
if (err)
-   DRM_ERROR("Failed to restore doorbell to %d, err %d\n",
-   db_id, err);
+   DRM_WARN("Failed to restore doorbell to %d, err %d\n",
+db_id, err);
 
/* Read back & verify all doorbell registers */
for (i = 0; i < GUC_MAX_DOORBELLS; ++i)
@@ -834,8 +832,6 @@ static void guc_init_doorbell_hw(struct intel_guc *guc)
return client;
 
 err:
-   DRM_ERROR("FAILED to create priority %u GuC client!\n", priority);
-
guc_client_free(dev_priv, client);
return NULL;
 }
@@ -1015,7 +1011,7 @@ int i915_guc_submission_enable(struct drm_i915_private 
*dev_priv)
  GUC_CTX_PRIORITY_KMD_NORMAL,
  dev_priv->kernel_context);
if (!client) {
-   DRM_ERROR("Failed to create execbuf guc_client\n");
+   DRM_ERROR("Failed to create normal GuC client!\n");
return -ENOMEM;
}
 
-- 
1.9.1

___
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: Initialize legacy semaphores from engine hw id indexed array

[Tvrtko Ursulin]

On 11/08/16 11:53, Chris Wilson wrote:

On Thu, Aug 11, 2016 at 11:43:38AM +0100, Tvrtko Ursulin wrote:

+#define I915_GEN6_SEMA_ENGINES 4


#define GEN6_SEMAPHORE_LAST VECS_HW

In theory, I915 and GEN6 are part of the same prefix class.

With that change and follow through for the inclusive test,
Reviewed-by: Chris Wilson 


Sent v2. Please can you check that it looks like you wanted there, since 
I did not carry this rb just in case?


Regards,

Tvrtko

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

[Intel-gfx] [PATCH v2] drm/i915: Initialize legacy semaphores from engine hw id indexed array

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Build the legacy semaphore initialisation array using the engine
hardware ids instead of driver internal ones. This makes the
static array size dependent only on the number of gen6 semaphore
engines.

Also makes the per-engine semaphore wait and signal tables
hardware id indexed saving some more space.

v2: Refactor I915_GEN6_NUM_ENGINES to GEN6_SEMAPHORE_LAST. (Chris Wilson)

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_ringbuffer.c | 55 +
 drivers/gpu/drm/i915/intel_ringbuffer.h |  5 +--
 2 files changed, 32 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index ed19868df9c6..d38e7b94f728 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1385,8 +1385,7 @@ static int gen6_signal(struct drm_i915_gem_request *req)
 {
struct intel_ring *ring = req->ring;
struct drm_i915_private *dev_priv = req->i915;
-   struct intel_engine_cs *useless;
-   enum intel_engine_id id;
+   struct intel_engine_cs *engine;
int ret, num_rings;
 
num_rings = INTEL_INFO(dev_priv)->num_rings;
@@ -1394,9 +1393,13 @@ static int gen6_signal(struct drm_i915_gem_request *req)
if (ret)
return ret;
 
-   for_each_engine_id(useless, dev_priv, id) {
-   i915_reg_t mbox_reg = req->engine->semaphore.mbox.signal[id];
+   for_each_engine(engine, dev_priv) {
+   i915_reg_t mbox_reg;
+
+   if (engine->hw_id > GEN6_SEMAPHORE_LAST)
+   continue;
 
+   mbox_reg = req->engine->semaphore.mbox.signal[engine->hw_id];
if (i915_mmio_reg_valid(mbox_reg)) {
intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
intel_ring_emit_reg(ring, mbox_reg);
@@ -1543,7 +1546,7 @@ gen6_ring_sync_to(struct drm_i915_gem_request *req,
u32 dw1 = MI_SEMAPHORE_MBOX |
  MI_SEMAPHORE_COMPARE |
  MI_SEMAPHORE_REGISTER;
-   u32 wait_mbox = signal->engine->semaphore.mbox.wait[req->engine->id];
+   u32 wait_mbox = signal->engine->semaphore.mbox.wait[req->engine->hw_id];
int ret;
 
WARN_ON(wait_mbox == MI_SEMAPHORE_SYNC_INVALID);
@@ -2671,41 +2674,41 @@ static void intel_ring_init_semaphores(struct 
drm_i915_private *dev_priv,
 * initialized as INVALID.  Gen8 will initialize the
 * sema between VCS2 and RCS later.
 */
-   for (i = 0; i < I915_NUM_ENGINES; i++) {
+   for (i = 0; i <= GEN6_SEMAPHORE_LAST; i++) {
static const struct {
u32 wait_mbox;
i915_reg_t mbox_reg;
-   } sem_data[I915_NUM_ENGINES][I915_NUM_ENGINES] = {
-   [RCS] = {
-   [VCS] =  { .wait_mbox = 
MI_SEMAPHORE_SYNC_RV,  .mbox_reg = GEN6_VRSYNC },
-   [BCS] =  { .wait_mbox = 
MI_SEMAPHORE_SYNC_RB,  .mbox_reg = GEN6_BRSYNC },
-   [VECS] = { .wait_mbox = 
MI_SEMAPHORE_SYNC_RVE, .mbox_reg = GEN6_VERSYNC },
+   } sem_data[GEN6_SEMAPHORE_LAST + 1][GEN6_SEMAPHORE_LAST 
+ 1] = {
+   [RCS_HW] = {
+   [VCS_HW] =  { .wait_mbox = 
MI_SEMAPHORE_SYNC_RV,  .mbox_reg = GEN6_VRSYNC },
+   [BCS_HW] =  { .wait_mbox = 
MI_SEMAPHORE_SYNC_RB,  .mbox_reg = GEN6_BRSYNC },
+   [VECS_HW] = { .wait_mbox = 
MI_SEMAPHORE_SYNC_RVE, .mbox_reg = GEN6_VERSYNC },
},
-   [VCS] = {
-   [RCS] =  { .wait_mbox = 
MI_SEMAPHORE_SYNC_VR,  .mbox_reg = GEN6_RVSYNC },
-   [BCS] =  { .wait_mbox = 
MI_SEMAPHORE_SYNC_VB,  .mbox_reg = GEN6_BVSYNC },
-   [VECS] = { .wait_mbox = 
MI_SEMAPHORE_SYNC_VVE, .mbox_reg = GEN6_VEVSYNC },
+   [VCS_HW] = {
+   [RCS_HW] =  { .wait_mbox = 
MI_SEMAPHORE_SYNC_VR,  .mbox_reg = GEN6_RVSYNC },
+   [BCS_HW] =  { .wait_mbox = 
MI_SEMAPHORE_SYNC_VB,  .mbox_reg = GEN6_BVSYNC },
+   [VECS_HW] = { .wait_mbox = 
MI_SEMAPHORE_SYNC_VVE, .mbox_reg = GEN6_VEVSYNC },
},
-   [BCS] = {
-   [RCS] =  { .wait_mbox = 
MI_SEMAPHORE_SYNC_BR,  .mbox_reg = GEN6_RBSYNC },
-   [VCS] =  { .wait_mbox = 
MI_SEMAPHORE_SYNC_BV,  .mbox_reg = GEN6_VBSYNC },
- 

Re: [Intel-gfx] [PATCH v4 2/6] drm/i915/huc: Unified css_header struct for GuC and HuC

[Antoine, Peter]

I'll add the blank lines.
Patched should be turned around today.

Thanks for the review.

Peter.

-Original Message-
From: Gordon, David S 
Sent: Thursday, August 11, 2016 12:03 PM
To: Antoine, Peter ; intel-gfx@lists.freedesktop.org
Cc: Alex Dai 
Subject: Re: [PATCH v4 2/6] drm/i915/huc: Unified css_header struct for GuC and 
HuC

On 04/08/16 09:16, Peter Antoine wrote:
> HuC firmware css header has almost exactly same definition as GuC 
> firmware except for the sw_version. Also, add a new member fw_type 
> into intel_uc_fw to indicate what kind of fw it is. So, the loader 
> will pull right sw_version from header.
>
> v2: rebased on-top of drm-intel-nightly
> v3: rebased on-top of drm-intel-nightly (again).
>
> Signed-off-by: Alex Dai 
> Signed-off-by: Peter Antoine 
> ---
>  drivers/gpu/drm/i915/intel_guc.h|  4 
>  drivers/gpu/drm/i915/intel_guc_fwif.h   | 16 ++---
>  drivers/gpu/drm/i915/intel_guc_loader.c | 40 
> ++---
>  3 files changed, 44 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_guc.h 
> b/drivers/gpu/drm/i915/intel_guc.h
> index 02adcfc..ebf9c8d 100644
> --- a/drivers/gpu/drm/i915/intel_guc.h
> +++ b/drivers/gpu/drm/i915/intel_guc.h
> @@ -97,6 +97,9 @@ enum intel_uc_fw_status {
>   UC_FIRMWARE_SUCCESS
>  };
>
> +#define UC_FW_TYPE_GUC   0
> +#define UC_FW_TYPE_HUC   1
> +
>  /*
>   * This structure encapsulates all the data needed during the process
>   * of fetching, caching, and loading the firmware image into the GuC.
> @@ -114,6 +117,7 @@ struct intel_uc_fw {
>   uint16_t major_ver_found;
>   uint16_t minor_ver_found;
>
> + uint32_t fw_type;
>   uint32_t header_size;
>   uint32_t header_offset;
>   uint32_t rsa_size;
> diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h 
> b/drivers/gpu/drm/i915/intel_guc_fwif.h
> index 944786d..a69ee36 100644
> --- a/drivers/gpu/drm/i915/intel_guc_fwif.h
> +++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
> @@ -154,7 +154,7 @@
>   * The GuC firmware layout looks like this:
>   *
>   * +---+
> - * |guc_css_header |
> + * | uc_css_header |
>   * | contains major/minor version  |
>   * +---+
>   * | uCode |
> @@ -180,9 +180,16 @@
>   * 3. Length info of each component can be found in header, in dwords.
>   * 4. Modulus and exponent key are not required by driver. They may not 
> appear
>   * in fw. So driver will load a truncated firmware in this case.
> + *
> + * HuC firmware layout is same as GuC firmware.
> + *
> + * HuC firmware css header is different. However, the only difference 
> + is where
> + * the version information is saved. The uc_css_header is unified to 
> + support
> + * both. Driver should get HuC version from 
> + uc_css_header.huc_sw_version, while
> + * uc_css_header.guc_sw_version for GuC.
>   */
>
> -struct guc_css_header {
> +struct uc_css_header {
>   uint32_t module_type;
>   /* header_size includes all non-uCode bits, including css_header, rsa
>* key, modulus key and exponent data. */ @@ -213,7 +220,10 @@ 
> struct guc_css_header {
>
>   char username[8];
>   char buildnumber[12];
> - uint32_t device_id;
> + union {
> + uint32_t device_id;
> + uint32_t huc_sw_version;
> + };
>   uint32_t guc_sw_version;
>   uint32_t prod_preprod_fw;
>   uint32_t reserved[12];
> diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
> b/drivers/gpu/drm/i915/intel_guc_loader.c
> index 25c9a91..d248ccd 100644
> --- a/drivers/gpu/drm/i915/intel_guc_loader.c
> +++ b/drivers/gpu/drm/i915/intel_guc_loader.c
> @@ -555,7 +555,7 @@ void intel_uc_fw_fetch(struct drm_device *dev, 
> struct intel_uc_fw *uc_fw)  {
>   struct drm_i915_gem_object *obj;
>   const struct firmware *fw;
> - struct guc_css_header *css;
> + struct uc_css_header *css;
>   size_t size;
>   int err;
>
> @@ -572,19 +572,19 @@ void intel_uc_fw_fetch(struct drm_device *dev, struct 
> intel_uc_fw *uc_fw)
>   uc_fw->uc_fw_path, fw);
>
>   /* Check the size of the blob before examining buffer contents */
> - if (fw->size < sizeof(struct guc_css_header)) {
> + if (fw->size < sizeof(struct uc_css_header)) {
>   DRM_ERROR("Firmware header is missing\n");
>   goto fail;
>   }
>
> - css = (struct guc_css_header *)fw->data;
> + css = (struct uc_css_header *)fw->data;
>
>   /* Firmware bits always start from header */
>   uc_fw->header_offset = 0;
>   uc_fw->header_size = (css->header_size_dw - css->modulus_size_dw -
>   css->key_size_dw - css->exponent_size_dw) * sizeof(u32);
>
> - if (uc_fw->header_size != sizeof(struct guc_css_header)) {
> + if (uc_fw->header_size != 

Re: [Intel-gfx] [PATCH v4 2/6] drm/i915/huc: Unified css_header struct for GuC and HuC

[Dave Gordon]

On 04/08/16 09:16, Peter Antoine wrote:

HuC firmware css header has almost exactly same definition as GuC
firmware except for the sw_version. Also, add a new member fw_type
into intel_uc_fw to indicate what kind of fw it is. So, the loader
will pull right sw_version from header.

v2: rebased on-top of drm-intel-nightly
v3: rebased on-top of drm-intel-nightly (again).

Signed-off-by: Alex Dai 
Signed-off-by: Peter Antoine 
---
 drivers/gpu/drm/i915/intel_guc.h|  4 
 drivers/gpu/drm/i915/intel_guc_fwif.h   | 16 ++---
 drivers/gpu/drm/i915/intel_guc_loader.c | 40 ++---
 3 files changed, 44 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 02adcfc..ebf9c8d 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -97,6 +97,9 @@ enum intel_uc_fw_status {
UC_FIRMWARE_SUCCESS
 };

+#define UC_FW_TYPE_GUC 0
+#define UC_FW_TYPE_HUC 1
+
 /*
  * This structure encapsulates all the data needed during the process
  * of fetching, caching, and loading the firmware image into the GuC.
@@ -114,6 +117,7 @@ struct intel_uc_fw {
uint16_t major_ver_found;
uint16_t minor_ver_found;

+   uint32_t fw_type;
uint32_t header_size;
uint32_t header_offset;
uint32_t rsa_size;
diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/intel_guc_fwif.h
index 944786d..a69ee36 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
@@ -154,7 +154,7 @@
  * The GuC firmware layout looks like this:
  *
  * +---+
- * |guc_css_header |
+ * | uc_css_header |
  * | contains major/minor version  |
  * +---+
  * | uCode |
@@ -180,9 +180,16 @@
  * 3. Length info of each component can be found in header, in dwords.
  * 4. Modulus and exponent key are not required by driver. They may not appear
  * in fw. So driver will load a truncated firmware in this case.
+ *
+ * HuC firmware layout is same as GuC firmware.
+ *
+ * HuC firmware css header is different. However, the only difference is where
+ * the version information is saved. The uc_css_header is unified to support
+ * both. Driver should get HuC version from uc_css_header.huc_sw_version, while
+ * uc_css_header.guc_sw_version for GuC.
  */

-struct guc_css_header {
+struct uc_css_header {
uint32_t module_type;
/* header_size includes all non-uCode bits, including css_header, rsa
 * key, modulus key and exponent data. */
@@ -213,7 +220,10 @@ struct guc_css_header {

char username[8];
char buildnumber[12];
-   uint32_t device_id;
+   union {
+   uint32_t device_id;
+   uint32_t huc_sw_version;
+   };
uint32_t guc_sw_version;
uint32_t prod_preprod_fw;
uint32_t reserved[12];
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 25c9a91..d248ccd 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -555,7 +555,7 @@ void intel_uc_fw_fetch(struct drm_device *dev, struct 
intel_uc_fw *uc_fw)
 {
struct drm_i915_gem_object *obj;
const struct firmware *fw;
-   struct guc_css_header *css;
+   struct uc_css_header *css;
size_t size;
int err;

@@ -572,19 +572,19 @@ void intel_uc_fw_fetch(struct drm_device *dev, struct 
intel_uc_fw *uc_fw)
uc_fw->uc_fw_path, fw);

/* Check the size of the blob before examining buffer contents */
-   if (fw->size < sizeof(struct guc_css_header)) {
+   if (fw->size < sizeof(struct uc_css_header)) {
DRM_ERROR("Firmware header is missing\n");
goto fail;
}

-   css = (struct guc_css_header *)fw->data;
+   css = (struct uc_css_header *)fw->data;

/* Firmware bits always start from header */
uc_fw->header_offset = 0;
uc_fw->header_size = (css->header_size_dw - css->modulus_size_dw -
css->key_size_dw - css->exponent_size_dw) * sizeof(u32);

-   if (uc_fw->header_size != sizeof(struct guc_css_header)) {
+   if (uc_fw->header_size != sizeof(struct uc_css_header)) {
DRM_ERROR("CSS header definition mismatch\n");
goto fail;
}
@@ -608,21 +608,35 @@ void intel_uc_fw_fetch(struct drm_device *dev, struct 
intel_uc_fw *uc_fw)
goto fail;
}

-   /* Header and uCode will be loaded to WOPCM. Size of the two. */
-   size = uc_fw->header_size + uc_fw->ucode_size;
-   if (size > guc_wopcm_size(to_i915(dev))) {
-   DRM_ERROR("Firmware is too large to fit in WOPCM\n");
-   goto fail;
-   }
-

Re: [Intel-gfx] [PATCH 25/33] drm/i915: Use VMA for wa_ctx tracking

[Chris Wilson]

On Thu, Aug 11, 2016 at 01:53:40PM +0300, Joonas Lahtinen wrote:
> On su, 2016-08-07 at 15:45 +0100, Chris Wilson wrote:
> > @@ -2019,9 +2023,9 @@ populate_lr_context(struct i915_gem_context *ctx,
> >        RING_INDIRECT_CTX(engine->mmio_base), 0);
> >     ASSIGN_CTX_REG(reg_state, CTX_RCS_INDIRECT_CTX_OFFSET,
> >        RING_INDIRECT_CTX_OFFSET(engine->mmio_base), 0);
> > -   if (engine->wa_ctx.obj) {
> > +   if (engine->wa_ctx.vma) {
> >     struct i915_ctx_workarounds *wa_ctx = >wa_ctx;
> > -   uint32_t ggtt_offset = 
> > i915_gem_obj_ggtt_offset(wa_ctx->obj);
> > +   u32 ggtt_offset = wa_ctx->vma->node.start;
> 
> lower_32_bits()?

I considered, I didn't to keep the changes to a minimum plus I've a
slight unease about making it seem like we don't care about the upper 32
bits.

static inline u32 i915_ggtt_offset(vma)
{
GEM_BUG_ON(upper_32_bits(vma->node.start));
return lower_32_bits(vma->node.start);
}

is possibly overkill but stops me feeling uneasy about the
seeming truncation. Is this something that UBSAN detects?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 1/6] drm/i915/guc: Make the GuC fw loading helper functions general

[Antoine, Peter]

Just rebasing now.
Is the other patch ok?

Peter.

-Original Message-
From: Gordon, David S 
Sent: Thursday, August 11, 2016 11:56 AM
To: Antoine, Peter ; intel-gfx@lists.freedesktop.org
Cc: Alex Dai 
Subject: Re: [PATCH v4 1/6] drm/i915/guc: Make the GuC fw loading helper 
functions general

On 04/08/16 09:16, Peter Antoine wrote:
> Rename some of the GuC fw loading code to make them more general. We 
> will utilise them for HuC loading as well.
>  s/intel_guc_fw/intel_uc_fw/g
>  s/GUC_FIRMWARE/UC_FIRMWARE/g
>
> Struct intel_guc_fw is renamed to intel_uc_fw. Prefix of tts members, 
> such as 'guc' or 'guc_fw' either is renamed to 'uc' or removed for 
> same purpose.
>
> v2: rebased on top of nightly.
> reapplied the search/replace as upstream code as changed.
> v3: rebased again on drm-nightly.
> v4: removed G from messages in shared fw fetch function.
>
> Signed-off-by: Alex Dai 
> Signed-off-by: Peter Antoine 
> Reviewed-by: Dave Gordon 

R-b can carry over again, but this will need (ANOTHER!) rebase as Chris has 
nuked one of the functions called below.

> ---
>  drivers/gpu/drm/i915/i915_debugfs.c|  12 +--
>  drivers/gpu/drm/i915/i915_guc_submission.c |   4 +-
>  drivers/gpu/drm/i915/intel_guc.h   |  39 +++
>  drivers/gpu/drm/i915/intel_guc_loader.c| 160 
> ++---
>  4 files changed, 108 insertions(+), 107 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 531ca02..5df7bd3 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2490,7 +2490,7 @@ static int i915_guc_load_status_info(struct 
> seq_file *m, void *data)  {
>   struct drm_info_node *node = m->private;
>   struct drm_i915_private *dev_priv = to_i915(node->minor->dev);
> - struct intel_guc_fw *guc_fw = _priv->guc.guc_fw;
> + struct intel_uc_fw *guc_fw = _priv->guc.guc_fw;
>   u32 tmp, i;
>
>   if (!HAS_GUC_UCODE(dev_priv))
> @@ -2498,15 +2498,15 @@ static int i915_guc_load_status_info(struct 
> seq_file *m, void *data)
>
>   seq_printf(m, "GuC firmware status:\n");
>   seq_printf(m, "\tpath: %s\n",
> - guc_fw->guc_fw_path);
> + guc_fw->uc_fw_path);
>   seq_printf(m, "\tfetch: %s\n",
> - intel_guc_fw_status_repr(guc_fw->guc_fw_fetch_status));
> + intel_uc_fw_status_repr(guc_fw->fetch_status));
>   seq_printf(m, "\tload: %s\n",
> - intel_guc_fw_status_repr(guc_fw->guc_fw_load_status));
> + intel_uc_fw_status_repr(guc_fw->load_status));
>   seq_printf(m, "\tversion wanted: %d.%d\n",
> - guc_fw->guc_fw_major_wanted, guc_fw->guc_fw_minor_wanted);
> + guc_fw->major_ver_wanted, guc_fw->minor_ver_wanted);
>   seq_printf(m, "\tversion found: %d.%d\n",
> - guc_fw->guc_fw_major_found, guc_fw->guc_fw_minor_found);
> + guc_fw->major_ver_found, guc_fw->minor_ver_found);
>   seq_printf(m, "\theader: offset is %d; size = %d\n",
>   guc_fw->header_offset, guc_fw->header_size);
>   seq_printf(m, "\tuCode: offset is %d; size = %d\n", diff --git 
> a/drivers/gpu/drm/i915/i915_guc_submission.c 
> b/drivers/gpu/drm/i915/i915_guc_submission.c
> index 01c1c16..f665a87 100644
> --- a/drivers/gpu/drm/i915/i915_guc_submission.c
> +++ b/drivers/gpu/drm/i915/i915_guc_submission.c
> @@ -1044,7 +1044,7 @@ int intel_guc_suspend(struct drm_device *dev)
>   struct i915_gem_context *ctx;
>   u32 data[3];
>
> - if (guc->guc_fw.guc_fw_load_status != GUC_FIRMWARE_SUCCESS)
> + if (guc->guc_fw.load_status != UC_FIRMWARE_SUCCESS)
>   return 0;
>
>   ctx = dev_priv->kernel_context;
> @@ -1070,7 +1070,7 @@ int intel_guc_resume(struct drm_device *dev)
>   struct i915_gem_context *ctx;
>   u32 data[3];
>
> - if (guc->guc_fw.guc_fw_load_status != GUC_FIRMWARE_SUCCESS)
> + if (guc->guc_fw.load_status != UC_FIRMWARE_SUCCESS)
>   return 0;
>
>   ctx = dev_priv->kernel_context;
> diff --git a/drivers/gpu/drm/i915/intel_guc.h 
> b/drivers/gpu/drm/i915/intel_guc.h
> index 3e3e743..02adcfc 100644
> --- a/drivers/gpu/drm/i915/intel_guc.h
> +++ b/drivers/gpu/drm/i915/intel_guc.h
> @@ -90,29 +90,29 @@ struct i915_guc_client {
>   uint64_t submissions[I915_NUM_ENGINES];  };
>
> -enum intel_guc_fw_status {
> - GUC_FIRMWARE_FAIL = -1,
> - GUC_FIRMWARE_NONE = 0,
> - GUC_FIRMWARE_PENDING,
> - GUC_FIRMWARE_SUCCESS
> +enum intel_uc_fw_status {
> + UC_FIRMWARE_FAIL = -1,
> + UC_FIRMWARE_NONE = 0,
> + UC_FIRMWARE_PENDING,
> + UC_FIRMWARE_SUCCESS
>  };
>
>  /*
>   * This structure encapsulates all the data needed during the process
>   * of fetching, caching, and loading the firmware image into the GuC.
>   */
> -struct intel_guc_fw {
> -   

Re: [Intel-gfx] [PATCH v7 3/5] drm/i915: Check pixel rate for DP to VGA dongle

[Daniel Vetter]

On Thu, Aug 11, 2016 at 01:51:42PM +0300, Ville Syrjälä wrote:
> On Thu, Aug 11, 2016 at 12:43:39PM +0300, Mika Kahola wrote:
> > On Thu, 2016-08-11 at 10:18 +0300, Ville Syrjälä wrote:
> > > On Mon, Aug 08, 2016 at 04:00:28PM +0300, Mika Kahola wrote:
> > > > Filter out a mode that exceeds the max pixel rate setting
> > > > for DP to VGA dongle. This is defined in DPCD register 0x81
> > > > if detailed cap info i.e. info field is 4 bytes long and
> > > > it is available for DP downstream port.
> > > > 
> > > > The register defines the pixel rate divided by 8 in MP/s.
> > > > 
> > > > v2: DPCD read outs and computation moved to drm (Ville, Daniel)
> > > > v3: Sink pixel rate computation moved to drm_dp_max_sink_dotclock()
> > > > function (Daniel)
> > > > v4: Use of drm_dp_helper.c routines to compute max pixel clock (Ville)
> > > > v5: Use of intel_dp->downstream_ports to read out port capabilities.
> > > > Code restructuring (Ville)
> > > > v6: Move DP branch device check to drm_dp_helper.c (Daniel)
> > > > 
> > > > Signed-off-by: Mika Kahola 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_dp.c | 25 -
> > > >  1 file changed, 24 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > index 21b04c3..e990c8b 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > @@ -190,6 +190,26 @@ intel_dp_max_data_rate(int max_link_clock, int 
> > > > max_lanes)
> > > > return (max_link_clock * max_lanes * 8) / 10;
> > > >  }
> > > >  
> > > > +static int
> > > > +intel_dp_downstream_max_dotclock(struct intel_dp *intel_dp, int dotclk)
> > > > +{
> > > 
> > > I would just
> > > 
> > > {
> > >   int max_dotclk = dev_priv->max_dotclk_freq;
> > > 
> > >   ds_max_dotclk = ...;
> > >   if (ds_dotclk != 0)
> > >   max_dotclk = min(max_dotclk, ds_max_dotclk);
> > > 
> > >   return max_dotclk;
> > > }
> > > 
> > > > +   int ds_dotclk;
> > > > +   int type;
> > > > +
> > > > +   ds_dotclk = drm_dp_downstream_max_clock(intel_dp->dpcd,
> > > > +   
> > > > intel_dp->downstream_ports);
> > > > +
> > > > +   if (ds_dotclk == 0)
> > > > +   return dotclk;
> > > > +
> > > > +   type = intel_dp->downstream_ports[0] & DP_DS_PORT_TYPE_MASK;
> > > > +   
> > > > +   if (type != DP_DS_PORT_TYPE_VGA)
> > > > +   return dotclk;
> > > 
> > > Why isn't drm_dp_downstream_max_clock() handling all of it already?
> > > Why are we even checking for !=VGA?
> > The routine drm_dp_downstream_max_clock returns the clock rate which can
> > be dotclock (VGA only) or TMDS clock (for DVI, HDMI, DP++). Here, we
> > need to have a check for this as we are only interested to update VGA
> > dotclock value.
> 
> We should handle it all. Actually I'm not even sure how we're supposed
> to deal with the downstream port max TMDS clock since for HDMI that
> depends on the bpc, but since this is about a DP->HDMI conversion, I
> don't know if we have to take the downstream port max TMDS clock into
> account when choosing the bpc over the DP link as well. I suppose that's
> possible if the dongle can't change change the bpc, and instead just
> passes things through. I think this is one of those places where the
> DP spec is way too unclear. But for DP->VGA there is no clock going out
> the other end, so it must be just about the limits of the DP input or
> the DAC.

I guess we should defensively assume that the tmds clock limit is both for
the input and the output signal, worst case, for the dp->hdmi dongle?
Except when it's a passive level-shifter only one ofc.
-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

Re: [Intel-gfx] [PATCH v4 1/6] drm/i915/guc: Make the GuC fw loading helper functions general

[Dave Gordon]

On 04/08/16 09:16, Peter Antoine wrote:

Rename some of the GuC fw loading code to make them more general. We
will utilise them for HuC loading as well.
 s/intel_guc_fw/intel_uc_fw/g
 s/GUC_FIRMWARE/UC_FIRMWARE/g

Struct intel_guc_fw is renamed to intel_uc_fw. Prefix of tts members,
such as 'guc' or 'guc_fw' either is renamed to 'uc' or removed for
same purpose.

v2: rebased on top of nightly.
reapplied the search/replace as upstream code as changed.
v3: rebased again on drm-nightly.
v4: removed G from messages in shared fw fetch function.

Signed-off-by: Alex Dai 
Signed-off-by: Peter Antoine 
Reviewed-by: Dave Gordon 


R-b can carry over again, but this will need (ANOTHER!) rebase as Chris 
has nuked one of the functions called below.



---
 drivers/gpu/drm/i915/i915_debugfs.c|  12 +--
 drivers/gpu/drm/i915/i915_guc_submission.c |   4 +-
 drivers/gpu/drm/i915/intel_guc.h   |  39 +++
 drivers/gpu/drm/i915/intel_guc_loader.c| 160 ++---
 4 files changed, 108 insertions(+), 107 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 531ca02..5df7bd3 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2490,7 +2490,7 @@ static int i915_guc_load_status_info(struct seq_file *m, 
void *data)
 {
struct drm_info_node *node = m->private;
struct drm_i915_private *dev_priv = to_i915(node->minor->dev);
-   struct intel_guc_fw *guc_fw = _priv->guc.guc_fw;
+   struct intel_uc_fw *guc_fw = _priv->guc.guc_fw;
u32 tmp, i;

if (!HAS_GUC_UCODE(dev_priv))
@@ -2498,15 +2498,15 @@ static int i915_guc_load_status_info(struct seq_file 
*m, void *data)

seq_printf(m, "GuC firmware status:\n");
seq_printf(m, "\tpath: %s\n",
-   guc_fw->guc_fw_path);
+   guc_fw->uc_fw_path);
seq_printf(m, "\tfetch: %s\n",
-   intel_guc_fw_status_repr(guc_fw->guc_fw_fetch_status));
+   intel_uc_fw_status_repr(guc_fw->fetch_status));
seq_printf(m, "\tload: %s\n",
-   intel_guc_fw_status_repr(guc_fw->guc_fw_load_status));
+   intel_uc_fw_status_repr(guc_fw->load_status));
seq_printf(m, "\tversion wanted: %d.%d\n",
-   guc_fw->guc_fw_major_wanted, guc_fw->guc_fw_minor_wanted);
+   guc_fw->major_ver_wanted, guc_fw->minor_ver_wanted);
seq_printf(m, "\tversion found: %d.%d\n",
-   guc_fw->guc_fw_major_found, guc_fw->guc_fw_minor_found);
+   guc_fw->major_ver_found, guc_fw->minor_ver_found);
seq_printf(m, "\theader: offset is %d; size = %d\n",
guc_fw->header_offset, guc_fw->header_size);
seq_printf(m, "\tuCode: offset is %d; size = %d\n",
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 01c1c16..f665a87 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -1044,7 +1044,7 @@ int intel_guc_suspend(struct drm_device *dev)
struct i915_gem_context *ctx;
u32 data[3];

-   if (guc->guc_fw.guc_fw_load_status != GUC_FIRMWARE_SUCCESS)
+   if (guc->guc_fw.load_status != UC_FIRMWARE_SUCCESS)
return 0;

ctx = dev_priv->kernel_context;
@@ -1070,7 +1070,7 @@ int intel_guc_resume(struct drm_device *dev)
struct i915_gem_context *ctx;
u32 data[3];

-   if (guc->guc_fw.guc_fw_load_status != GUC_FIRMWARE_SUCCESS)
+   if (guc->guc_fw.load_status != UC_FIRMWARE_SUCCESS)
return 0;

ctx = dev_priv->kernel_context;
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 3e3e743..02adcfc 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -90,29 +90,29 @@ struct i915_guc_client {
uint64_t submissions[I915_NUM_ENGINES];
 };

-enum intel_guc_fw_status {
-   GUC_FIRMWARE_FAIL = -1,
-   GUC_FIRMWARE_NONE = 0,
-   GUC_FIRMWARE_PENDING,
-   GUC_FIRMWARE_SUCCESS
+enum intel_uc_fw_status {
+   UC_FIRMWARE_FAIL = -1,
+   UC_FIRMWARE_NONE = 0,
+   UC_FIRMWARE_PENDING,
+   UC_FIRMWARE_SUCCESS
 };

 /*
  * This structure encapsulates all the data needed during the process
  * of fetching, caching, and loading the firmware image into the GuC.
  */
-struct intel_guc_fw {
-   struct drm_device * guc_dev;
-   const char *guc_fw_path;
-   size_t  guc_fw_size;
-   struct drm_i915_gem_object *guc_fw_obj;
-   enum intel_guc_fw_statusguc_fw_fetch_status;
-   enum intel_guc_fw_statusguc_fw_load_status;
-
-   uint16_tguc_fw_major_wanted;
-   uint16_tguc_fw_minor_wanted;
-   

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Initialize legacy semaphores from engine hw id indexed array

[Chris Wilson]

On Thu, Aug 11, 2016 at 11:43:38AM +0100, Tvrtko Ursulin wrote:
> +#define I915_GEN6_SEMA_ENGINES 4

#define GEN6_SEMAPHORE_LAST VECS_HW

In theory, I915 and GEN6 are part of the same prefix class.

With that change and follow through for the inclusive test,
Reviewed-by: Chris Wilson 
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 1/6] drm/i915/guc: Make the GuC fw loading helper functions general

[Dave Gordon]

On 11/08/16 11:49, Dave Gordon wrote:

On 06/07/16 15:24, Peter Antoine wrote:

Rename some of the GuC fw loading code to make them more general. We
will utilise them for HuC loading as well.
 s/intel_guc_fw/intel_uc_fw/g
 s/GUC_FIRMWARE/UC_FIRMWARE/g

Struct intel_guc_fw is renamed to intel_uc_fw. Prefix of tts members,
such as 'guc' or 'guc_fw' either is renamed to 'uc' or removed for
same purpose.

v2: rebased on top of nightly.
reapplied the search/replace as upstream code as changed.
v3: rebased again on drm-nightly.

Signed-off-by: Alex Dai 
Signed-off-by: Peter Antoine 
Reviewed-by: Dave Gordon 


R-b can carry over again, but this will need (ANOTHER!) rebase as Chris
has nuked one of the functions called below.


---
 drivers/gpu/drm/i915/i915_debugfs.c|  12 +--
 drivers/gpu/drm/i915/i915_guc_submission.c |   4 +-
 drivers/gpu/drm/i915/intel_guc.h   |  39 
 drivers/gpu/drm/i915/intel_guc_loader.c| 146
++---
 4 files changed, 101 insertions(+), 100 deletions(-)


Ignore previous message, replied to wrong version :(

.Dave.

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

Re: [Intel-gfx] [PATCH 25/33] drm/i915: Use VMA for wa_ctx tracking

[Joonas Lahtinen]

On su, 2016-08-07 at 15:45 +0100, Chris Wilson wrote:
>  static int lrc_setup_wa_ctx_obj(struct intel_engine_cs *engine, u32 size)
>  {
> - int ret;
> + struct drm_i915_gem_object *obj;
> + struct i915_vma *vma;
> + int err;
>  
> - engine->wa_ctx.obj = i915_gem_object_create(>i915->drm,
> - PAGE_ALIGN(size));
> - if (IS_ERR(engine->wa_ctx.obj)) {
> - DRM_DEBUG_DRIVER("alloc LRC WA ctx backing obj failed.\n");
> - ret = PTR_ERR(engine->wa_ctx.obj);
> - engine->wa_ctx.obj = NULL;
> - return ret;
> + obj = i915_gem_object_create(>i915->drm, PAGE_ALIGN(size));
> + if (IS_ERR(obj))
> + return PTR_ERR(obj);
> +
> + vma = i915_vma_create(obj, >i915->ggtt.base, NULL);
> + if (IS_ERR(vma)) {
> + i915_gem_object_put(obj);
> + return PTR_ERR(vma);

Goto teardown; err = PTR_ERR(vma);

>   }
>  
> - ret = i915_gem_object_ggtt_pin(engine->wa_ctx.obj, NULL,
> -    0, PAGE_SIZE, PIN_HIGH);
> - if (ret) {
> - DRM_DEBUG_DRIVER("pin LRC WA ctx backing obj failed: %d\n",
> -  ret);
> - i915_gem_object_put(engine->wa_ctx.obj);
> - return ret;
> + err = i915_vma_pin(vma, 0, PAGE_SIZE, PIN_GLOBAL | PIN_HIGH);
> + if (err) {
> + i915_gem_object_put(obj);

Goto teardown.

> + return err;
>   }
>  
> + engine->wa_ctx.vma = vma;
>   return 0;
>  }
>  
> @@ -2019,9 +2023,9 @@ populate_lr_context(struct i915_gem_context *ctx,
>      RING_INDIRECT_CTX(engine->mmio_base), 0);
>   ASSIGN_CTX_REG(reg_state, CTX_RCS_INDIRECT_CTX_OFFSET,
>      RING_INDIRECT_CTX_OFFSET(engine->mmio_base), 0);
> - if (engine->wa_ctx.obj) {
> + if (engine->wa_ctx.vma) {
>   struct i915_ctx_workarounds *wa_ctx = >wa_ctx;
> - uint32_t ggtt_offset = 
> i915_gem_obj_ggtt_offset(wa_ctx->obj);
> + u32 ggtt_offset = wa_ctx->vma->node.start;

lower_32_bits()?

>  
>   reg_state[CTX_RCS_INDIRECT_CTX+1] =
>   (ggtt_offset + wa_ctx->indirect_ctx.offset * 
> sizeof(uint32_t)) |

With above addressed;

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v7 3/5] drm/i915: Check pixel rate for DP to VGA dongle

[Ville Syrjälä]

On Thu, Aug 11, 2016 at 12:43:39PM +0300, Mika Kahola wrote:
> On Thu, 2016-08-11 at 10:18 +0300, Ville Syrjälä wrote:
> > On Mon, Aug 08, 2016 at 04:00:28PM +0300, Mika Kahola wrote:
> > > Filter out a mode that exceeds the max pixel rate setting
> > > for DP to VGA dongle. This is defined in DPCD register 0x81
> > > if detailed cap info i.e. info field is 4 bytes long and
> > > it is available for DP downstream port.
> > > 
> > > The register defines the pixel rate divided by 8 in MP/s.
> > > 
> > > v2: DPCD read outs and computation moved to drm (Ville, Daniel)
> > > v3: Sink pixel rate computation moved to drm_dp_max_sink_dotclock()
> > > function (Daniel)
> > > v4: Use of drm_dp_helper.c routines to compute max pixel clock (Ville)
> > > v5: Use of intel_dp->downstream_ports to read out port capabilities.
> > > Code restructuring (Ville)
> > > v6: Move DP branch device check to drm_dp_helper.c (Daniel)
> > > 
> > > Signed-off-by: Mika Kahola 
> > > ---
> > >  drivers/gpu/drm/i915/intel_dp.c | 25 -
> > >  1 file changed, 24 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index 21b04c3..e990c8b 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -190,6 +190,26 @@ intel_dp_max_data_rate(int max_link_clock, int 
> > > max_lanes)
> > >   return (max_link_clock * max_lanes * 8) / 10;
> > >  }
> > >  
> > > +static int
> > > +intel_dp_downstream_max_dotclock(struct intel_dp *intel_dp, int dotclk)
> > > +{
> > 
> > I would just
> > 
> > {
> > int max_dotclk = dev_priv->max_dotclk_freq;
> > 
> > ds_max_dotclk = ...;
> > if (ds_dotclk != 0)
> > max_dotclk = min(max_dotclk, ds_max_dotclk);
> > 
> > return max_dotclk;
> > }
> > 
> > > + int ds_dotclk;
> > > + int type;
> > > +
> > > + ds_dotclk = drm_dp_downstream_max_clock(intel_dp->dpcd,
> > > + intel_dp->downstream_ports);
> > > +
> > > + if (ds_dotclk == 0)
> > > + return dotclk;
> > > +
> > > + type = intel_dp->downstream_ports[0] & DP_DS_PORT_TYPE_MASK;
> > > + 
> > > + if (type != DP_DS_PORT_TYPE_VGA)
> > > + return dotclk;
> > 
> > Why isn't drm_dp_downstream_max_clock() handling all of it already?
> > Why are we even checking for !=VGA?
> The routine drm_dp_downstream_max_clock returns the clock rate which can
> be dotclock (VGA only) or TMDS clock (for DVI, HDMI, DP++). Here, we
> need to have a check for this as we are only interested to update VGA
> dotclock value.

We should handle it all. Actually I'm not even sure how we're supposed
to deal with the downstream port max TMDS clock since for HDMI that
depends on the bpc, but since this is about a DP->HDMI conversion, I
don't know if we have to take the downstream port max TMDS clock into
account when choosing the bpc over the DP link as well. I suppose that's
possible if the dongle can't change change the bpc, and instead just
passes things through. I think this is one of those places where the
DP spec is way too unclear. But for DP->VGA there is no clock going out
the other end, so it must be just about the limits of the DP input or
the DAC.

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

Re: [Intel-gfx] [PATCH v3 1/6] drm/i915/guc: Make the GuC fw loading helper functions general

[Dave Gordon]

On 06/07/16 15:24, Peter Antoine wrote:

Rename some of the GuC fw loading code to make them more general. We
will utilise them for HuC loading as well.
 s/intel_guc_fw/intel_uc_fw/g
 s/GUC_FIRMWARE/UC_FIRMWARE/g

Struct intel_guc_fw is renamed to intel_uc_fw. Prefix of tts members,
such as 'guc' or 'guc_fw' either is renamed to 'uc' or removed for
same purpose.

v2: rebased on top of nightly.
reapplied the search/replace as upstream code as changed.
v3: rebased again on drm-nightly.

Signed-off-by: Alex Dai 
Signed-off-by: Peter Antoine 
Reviewed-by: Dave Gordon 


R-b can carry over again, but this will need (ANOTHER!) rebase as Chris 
has nuked one of the functions called below.



---
 drivers/gpu/drm/i915/i915_debugfs.c|  12 +--
 drivers/gpu/drm/i915/i915_guc_submission.c |   4 +-
 drivers/gpu/drm/i915/intel_guc.h   |  39 
 drivers/gpu/drm/i915/intel_guc_loader.c| 146 ++---
 4 files changed, 101 insertions(+), 100 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 3d05cae..9a6deff 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2498,7 +2498,7 @@ static int i915_guc_load_status_info(struct seq_file *m, 
void *data)
 {
struct drm_info_node *node = m->private;
struct drm_i915_private *dev_priv = to_i915(node->minor->dev);
-   struct intel_guc_fw *guc_fw = _priv->guc.guc_fw;
+   struct intel_uc_fw *guc_fw = _priv->guc.guc_fw;
u32 tmp, i;

if (!HAS_GUC_UCODE(dev_priv))
@@ -2506,15 +2506,15 @@ static int i915_guc_load_status_info(struct seq_file 
*m, void *data)

seq_printf(m, "GuC firmware status:\n");
seq_printf(m, "\tpath: %s\n",
-   guc_fw->guc_fw_path);
+   guc_fw->uc_fw_path);
seq_printf(m, "\tfetch: %s\n",
-   intel_guc_fw_status_repr(guc_fw->guc_fw_fetch_status));
+   intel_uc_fw_status_repr(guc_fw->fetch_status));
seq_printf(m, "\tload: %s\n",
-   intel_guc_fw_status_repr(guc_fw->guc_fw_load_status));
+   intel_uc_fw_status_repr(guc_fw->load_status));
seq_printf(m, "\tversion wanted: %d.%d\n",
-   guc_fw->guc_fw_major_wanted, guc_fw->guc_fw_minor_wanted);
+   guc_fw->major_ver_wanted, guc_fw->minor_ver_wanted);
seq_printf(m, "\tversion found: %d.%d\n",
-   guc_fw->guc_fw_major_found, guc_fw->guc_fw_minor_found);
+   guc_fw->major_ver_found, guc_fw->minor_ver_found);
seq_printf(m, "\theader: offset is %d; size = %d\n",
guc_fw->header_offset, guc_fw->header_size);
seq_printf(m, "\tuCode: offset is %d; size = %d\n",
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index bfc8bf6..5f88500 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -1038,7 +1038,7 @@ int intel_guc_suspend(struct drm_device *dev)
struct i915_gem_context *ctx;
u32 data[3];

-   if (guc->guc_fw.guc_fw_load_status != GUC_FIRMWARE_SUCCESS)
+   if (guc->guc_fw.load_status != UC_FIRMWARE_SUCCESS)
return 0;

ctx = dev_priv->kernel_context;
@@ -1064,7 +1064,7 @@ int intel_guc_resume(struct drm_device *dev)
struct i915_gem_context *ctx;
u32 data[3];

-   if (guc->guc_fw.guc_fw_load_status != GUC_FIRMWARE_SUCCESS)
+   if (guc->guc_fw.load_status != UC_FIRMWARE_SUCCESS)
return 0;

ctx = dev_priv->kernel_context;
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 3e3e743..02adcfc 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -90,29 +90,29 @@ struct i915_guc_client {
uint64_t submissions[I915_NUM_ENGINES];
 };

-enum intel_guc_fw_status {
-   GUC_FIRMWARE_FAIL = -1,
-   GUC_FIRMWARE_NONE = 0,
-   GUC_FIRMWARE_PENDING,
-   GUC_FIRMWARE_SUCCESS
+enum intel_uc_fw_status {
+   UC_FIRMWARE_FAIL = -1,
+   UC_FIRMWARE_NONE = 0,
+   UC_FIRMWARE_PENDING,
+   UC_FIRMWARE_SUCCESS
 };

 /*
  * This structure encapsulates all the data needed during the process
  * of fetching, caching, and loading the firmware image into the GuC.
  */
-struct intel_guc_fw {
-   struct drm_device * guc_dev;
-   const char *guc_fw_path;
-   size_t  guc_fw_size;
-   struct drm_i915_gem_object *guc_fw_obj;
-   enum intel_guc_fw_statusguc_fw_fetch_status;
-   enum intel_guc_fw_statusguc_fw_load_status;
-
-   uint16_tguc_fw_major_wanted;
-   uint16_tguc_fw_minor_wanted;
-   uint16_tguc_fw_major_found;
-   

Re: [Intel-gfx] [PATCH 24/33] drm/i915: Use VMA for render state page tracking

[Joonas Lahtinen]

On su, 2016-08-07 at 15:45 +0100, Chris Wilson wrote:
> @@ -24,7 +24,7 @@
>  #ifndef _I915_GEM_RENDER_STATE_H_
>  #define _I915_GEM_RENDER_STATE_H_
>  
> -#include 
> +struct drm_i915_gem_request;
>  

This patch almost only did what the title said...

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/2] drm/i915: Add enum for hardware engine identifiers

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Put the engine hardware id in the common header so they are
not only associated with the GuC since they are needed for
the legacy semaphores implementation.

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_engine_cs.c  | 14 +++---
 drivers/gpu/drm/i915/intel_ringbuffer.h | 10 --
 2 files changed, 15 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 186c12d07f99..ab942de88d9a 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -29,7 +29,7 @@
 static const struct engine_info {
const char *name;
unsigned exec_id;
-   unsigned guc_id;
+   enum intel_engine_hw_id hw_id;
u32 mmio_base;
unsigned irq_shift;
int (*init_legacy)(struct intel_engine_cs *engine);
@@ -38,7 +38,7 @@ static const struct engine_info {
[RCS] = {
.name = "render ring",
.exec_id = I915_EXEC_RENDER,
-   .guc_id = GUC_RENDER_ENGINE,
+   .hw_id = RCS_HW,
.mmio_base = RENDER_RING_BASE,
.irq_shift = GEN8_RCS_IRQ_SHIFT,
.init_execlists = logical_render_ring_init,
@@ -47,7 +47,7 @@ static const struct engine_info {
[BCS] = {
.name = "blitter ring",
.exec_id = I915_EXEC_BLT,
-   .guc_id = GUC_BLITTER_ENGINE,
+   .hw_id = BCS_HW,
.mmio_base = BLT_RING_BASE,
.irq_shift = GEN8_BCS_IRQ_SHIFT,
.init_execlists = logical_xcs_ring_init,
@@ -56,7 +56,7 @@ static const struct engine_info {
[VCS] = {
.name = "bsd ring",
.exec_id = I915_EXEC_BSD,
-   .guc_id = GUC_VIDEO_ENGINE,
+   .hw_id = VCS_HW,
.mmio_base = GEN6_BSD_RING_BASE,
.irq_shift = GEN8_VCS1_IRQ_SHIFT,
.init_execlists = logical_xcs_ring_init,
@@ -65,7 +65,7 @@ static const struct engine_info {
[VCS2] = {
.name = "bsd2 ring",
.exec_id = I915_EXEC_BSD,
-   .guc_id = GUC_VIDEO_ENGINE2,
+   .hw_id = VCS2_HW,
.mmio_base = GEN8_BSD2_RING_BASE,
.irq_shift = GEN8_VCS2_IRQ_SHIFT,
.init_execlists = logical_xcs_ring_init,
@@ -74,7 +74,7 @@ static const struct engine_info {
[VECS] = {
.name = "video enhancement ring",
.exec_id = I915_EXEC_VEBOX,
-   .guc_id = GUC_VIDEOENHANCE_ENGINE,
+   .hw_id = VECS_HW,
.mmio_base = VEBOX_RING_BASE,
.irq_shift = GEN8_VECS_IRQ_SHIFT,
.init_execlists = logical_xcs_ring_init,
@@ -93,7 +93,7 @@ intel_engine_setup(struct drm_i915_private *dev_priv,
engine->i915 = dev_priv;
engine->name = info->name;
engine->exec_id = info->exec_id;
-   engine->hw_id = engine->guc_id = info->guc_id;
+   engine->hw_id = engine->guc_id = info->hw_id;
engine->mmio_base = info->mmio_base;
engine->irq_shift = info->irq_shift;
 
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index ea2735144b2a..ac568808aeb1 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -146,8 +146,14 @@ struct intel_engine_cs {
 #define I915_NUM_ENGINES 5
 #define _VCS(n) (VCS + (n))
unsigned int exec_id;
-   unsigned int hw_id;
-   unsigned int guc_id; /* XXX same as hw_id? */
+   enum intel_engine_hw_id {
+   RCS_HW = 0,
+   VCS_HW,
+   BCS_HW,
+   VECS_HW,
+   VCS2_HW
+   } hw_id;
+   enum intel_engine_hw_id guc_id; /* XXX same as hw_id? */
u64 fence_context;
u32 mmio_base;
unsigned int irq_shift;
-- 
1.9.1

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

[Intel-gfx] [PATCH 0/2] Shrink and lock the size static gen6 semaphore init array

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Previous attempts to get rid of the static init table using the function
were not too popular so this time round I am trying to do it by chaging the
namespace of the engine identifiers used for indexing.

Going from driver internal engine id to hardware engine id allows us to
keep the table checked in size by limiting to the number of Gen6 engines.

I am not fully happy with the naming of new enums in intel_engine_hw_id so
feel free to suggest something nicer.

Tvrtko Ursulin (2):
  drm/i915: Add enum for hardware engine identifiers
  drm/i915: Initialize legacy semaphores from engine hw id indexed array

 drivers/gpu/drm/i915/intel_engine_cs.c  | 14 -
 drivers/gpu/drm/i915/intel_ringbuffer.c | 55 +
 drivers/gpu/drm/i915/intel_ringbuffer.h | 15 ++---
 3 files changed, 47 insertions(+), 37 deletions(-)

-- 
1.9.1

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

[Intel-gfx] [PATCH 2/2] drm/i915: Initialize legacy semaphores from engine hw id indexed array

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Build the legacy semaphore initialisation array using the engine
hardware ids instead of driver internal ones. This makes the
static array size dependent only on the number of gen6 semaphore
engines.

Also makes the per-engine semaphore wait and signal tables
hardware id indexed saving some more space.

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_ringbuffer.c | 55 +
 drivers/gpu/drm/i915/intel_ringbuffer.h |  5 +--
 2 files changed, 32 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index ed19868df9c6..a70157a65cfd 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1385,8 +1385,7 @@ static int gen6_signal(struct drm_i915_gem_request *req)
 {
struct intel_ring *ring = req->ring;
struct drm_i915_private *dev_priv = req->i915;
-   struct intel_engine_cs *useless;
-   enum intel_engine_id id;
+   struct intel_engine_cs *engine;
int ret, num_rings;
 
num_rings = INTEL_INFO(dev_priv)->num_rings;
@@ -1394,9 +1393,13 @@ static int gen6_signal(struct drm_i915_gem_request *req)
if (ret)
return ret;
 
-   for_each_engine_id(useless, dev_priv, id) {
-   i915_reg_t mbox_reg = req->engine->semaphore.mbox.signal[id];
+   for_each_engine(engine, dev_priv) {
+   i915_reg_t mbox_reg;
+
+   if (engine->hw_id >= I915_GEN6_SEMA_ENGINES)
+   continue;
 
+   mbox_reg = req->engine->semaphore.mbox.signal[engine->hw_id];
if (i915_mmio_reg_valid(mbox_reg)) {
intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
intel_ring_emit_reg(ring, mbox_reg);
@@ -1543,7 +1546,7 @@ gen6_ring_sync_to(struct drm_i915_gem_request *req,
u32 dw1 = MI_SEMAPHORE_MBOX |
  MI_SEMAPHORE_COMPARE |
  MI_SEMAPHORE_REGISTER;
-   u32 wait_mbox = signal->engine->semaphore.mbox.wait[req->engine->id];
+   u32 wait_mbox = signal->engine->semaphore.mbox.wait[req->engine->hw_id];
int ret;
 
WARN_ON(wait_mbox == MI_SEMAPHORE_SYNC_INVALID);
@@ -2671,41 +2674,41 @@ static void intel_ring_init_semaphores(struct 
drm_i915_private *dev_priv,
 * initialized as INVALID.  Gen8 will initialize the
 * sema between VCS2 and RCS later.
 */
-   for (i = 0; i < I915_NUM_ENGINES; i++) {
+   for (i = 0; i < I915_GEN6_SEMA_ENGINES; i++) {
static const struct {
u32 wait_mbox;
i915_reg_t mbox_reg;
-   } sem_data[I915_NUM_ENGINES][I915_NUM_ENGINES] = {
-   [RCS] = {
-   [VCS] =  { .wait_mbox = 
MI_SEMAPHORE_SYNC_RV,  .mbox_reg = GEN6_VRSYNC },
-   [BCS] =  { .wait_mbox = 
MI_SEMAPHORE_SYNC_RB,  .mbox_reg = GEN6_BRSYNC },
-   [VECS] = { .wait_mbox = 
MI_SEMAPHORE_SYNC_RVE, .mbox_reg = GEN6_VERSYNC },
+   } 
sem_data[I915_GEN6_SEMA_ENGINES][I915_GEN6_SEMA_ENGINES] = {
+   [RCS_HW] = {
+   [VCS_HW] =  { .wait_mbox = 
MI_SEMAPHORE_SYNC_RV,  .mbox_reg = GEN6_VRSYNC },
+   [BCS_HW] =  { .wait_mbox = 
MI_SEMAPHORE_SYNC_RB,  .mbox_reg = GEN6_BRSYNC },
+   [VECS_HW] = { .wait_mbox = 
MI_SEMAPHORE_SYNC_RVE, .mbox_reg = GEN6_VERSYNC },
},
-   [VCS] = {
-   [RCS] =  { .wait_mbox = 
MI_SEMAPHORE_SYNC_VR,  .mbox_reg = GEN6_RVSYNC },
-   [BCS] =  { .wait_mbox = 
MI_SEMAPHORE_SYNC_VB,  .mbox_reg = GEN6_BVSYNC },
-   [VECS] = { .wait_mbox = 
MI_SEMAPHORE_SYNC_VVE, .mbox_reg = GEN6_VEVSYNC },
+   [VCS_HW] = {
+   [RCS_HW] =  { .wait_mbox = 
MI_SEMAPHORE_SYNC_VR,  .mbox_reg = GEN6_RVSYNC },
+   [BCS_HW] =  { .wait_mbox = 
MI_SEMAPHORE_SYNC_VB,  .mbox_reg = GEN6_BVSYNC },
+   [VECS_HW] = { .wait_mbox = 
MI_SEMAPHORE_SYNC_VVE, .mbox_reg = GEN6_VEVSYNC },
},
-   [BCS] = {
-   [RCS] =  { .wait_mbox = 
MI_SEMAPHORE_SYNC_BR,  .mbox_reg = GEN6_RBSYNC },
-   [VCS] =  { .wait_mbox = 
MI_SEMAPHORE_SYNC_BV,  .mbox_reg = GEN6_VBSYNC },
-   [VECS] = { .wait_mbox = 

Re: [Intel-gfx] [PATCH 23/33] drm/i915: Use VMA as the primary tracker for semaphore page

[Joonas Lahtinen]

On su, 2016-08-07 at 15:45 +0100, Chris Wilson wrote:
> @@ -530,7 +530,7 @@ int i915_error_state_to_str(struct 
> drm_i915_error_state_buf *m,
>   }
>   }
>  
> - if ((obj = error->semaphore_obj)) {
> + if ((obj = error->semaphore)) {

Hate this kind of code which is direct result of copy paste... Adding
to TODO list.

>  static int gen8_rcs_signal(struct drm_i915_gem_request *req)
> @@ -2329,12 +2331,14 @@ void intel_engine_init_seqno(struct intel_engine_cs 
> *engine, u32 seqno)
>   if (HAS_VEBOX(dev_priv))
>   I915_WRITE(RING_SYNC_2(engine->mmio_base), 0);
>   }
> - if (dev_priv->semaphore_obj) {
> - struct drm_i915_gem_object *obj = dev_priv->semaphore_obj;
> + if (dev_priv->semaphore) {
> + struct drm_i915_gem_object *obj = dev_priv->semaphore->obj;
>   struct page *page = i915_gem_object_get_dirty_page(obj, 0);
>   void *semaphores = kmap(page);
>   memset(semaphores + GEN8_SEMAPHORE_OFFSET(engine->id, 0),
>      0, I915_NUM_ENGINES * gen8_semaphore_seqno_size);
> + drm_clflush_virt_range(semaphores + 
> GEN8_SEMAPHORE_OFFSET(engine->id, 0),
> +    I915_NUM_ENGINES * 
> gen8_semaphore_seqno_size);

Where did this hunk appear from? Did not expect based on the commit
message as there was no such thing :P

>   kunmap(page);
>   }
>   memset(engine->semaphore.sync_seqno, 0,
> @@ -2556,36 +2560,40 @@ static int gen6_ring_flush(struct 
> drm_i915_gem_request *req, u32 mode)
>  static void intel_ring_init_semaphores(struct drm_i915_private *dev_priv,
>      struct intel_engine_cs *engine)
>  {
> - struct drm_i915_gem_object *obj;
>   int ret, i;
>  
>   if (!i915.semaphores)
>   return;
>  
> - if (INTEL_GEN(dev_priv) >= 8 && !dev_priv->semaphore_obj) {
> + if (INTEL_GEN(dev_priv) >= 8 && !dev_priv->semaphore) {
> + struct drm_i915_gem_object *obj;
> + struct i915_vma *vma;
> +
>   obj = i915_gem_object_create(_priv->drm, 4096);
>   if (IS_ERR(obj)) {
> - DRM_ERROR("Failed to allocate semaphore bo. Disabling 
> semaphores\n");

Silencing a DRM_ERROR, maybe into commit message too.

>   i915.semaphores = 0;
> - } else {
> - i915_gem_object_set_cache_level(obj, I915_CACHE_LLC);

Right, this is traded for the drm_clflush_virt_range()? I'd add a
comment on top of the new location.

> - ret = i915_gem_object_ggtt_pin(obj, NULL,
> -    0, 0, PIN_HIGH);
> - if (ret != 0) {
> - i915_gem_object_put(obj);
> - DRM_ERROR("Failed to pin semaphore bo. 
> Disabling semaphores\n");
> - i915.semaphores = 0;
> - } else {
> - dev_priv->semaphore_obj = obj;
> - }
> + return;

Goto teardown;

>   }
> - }
>  
> - if (!i915.semaphores)
> - return;
> + vma = i915_vma_create(obj, _priv->ggtt.base, NULL);
> + if (IS_ERR(vma)) {
> + i915_gem_object_put(obj);
> + i915.semaphores = 0;
> + return;

Goto teardown.

> + }
> +
> + ret = i915_vma_pin(vma, 0, 0, PIN_GLOBAL | PIN_HIGH);
> + if (ret) {
> + i915_gem_object_put(obj);
> + i915.semaphores = 0;
> + return;

Goto teardown.

> + }
> +
> + dev_priv->semaphore = vma;
> + }
>  

Above addressed;

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] Revert "drm/fb-helper: Reduce READ_ONCE(master) to lockless_dereference"

[Daniel Vetter]

On Thu, Aug 11, 2016 at 11:50:21AM +0200, Johannes Berg wrote:
> From: Johannes Berg 
> 
> This reverts commit fa7d81bb3c269a2ee38b6e4d569d9eb8be1a78ad.
> 
> As Peter explained:
>   [...] lockless_dereference() is _stronger_ than READ_ONCE(), not weaker.
> 
>   [...]
> 
>   Also, clue is in the name: 'dereference', you don't actually dereference
>   the pointer here, only load it.
> 
> My next patch breaks compile on this, because it assumes you want to
> deference and thus also need the struct type visible (which it isn't
> here), so revert it.
> 
> Cc: Peter Zijlstra 
> Signed-off-by: Johannes Berg 

Reviewed-by: Daniel Vetter 

And ack-by: me for merging through whatever tree this makes sense for.
-Daniel

> ---
>  drivers/gpu/drm/drm_fb_helper.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index ce54e985d91b..0a06f9120b5a 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -464,7 +464,7 @@ static bool drm_fb_helper_is_bound(struct drm_fb_helper 
> *fb_helper)
>  
>   /* Sometimes user space wants everything disabled, so don't steal the
>* display if there's a master. */
> - if (lockless_dereference(dev->master))
> + if (READ_ONCE(dev->master))
>   return false;
>  
>   drm_for_each_crtc(crtc, dev) {
> -- 
> 2.8.1
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
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] ✗ Ro.CI.BAT: warning for drm/i915/guc: Consolidate firmware major-minor to one place (rev2)

[Tvrtko Ursulin]

On 10/08/16 17:58, Patchwork wrote:

== Series Details ==

Series: drm/i915/guc: Consolidate firmware major-minor to one place (rev2)
URL   : https://patchwork.freedesktop.org/series/9318/
State : warning

== Summary ==

Series 9318v2 drm/i915/guc: Consolidate firmware major-minor to one place
http://patchwork.freedesktop.org/api/1.0/series/9318/revisions/2/mbox

Test drv_module_reload_basic:
 skip   -> PASS   (fi-skl-i5-6260u)
Test kms_cursor_legacy:
 Subgroup basic-flip-vs-cursor-legacy:
 fail   -> PASS   (fi-hsw-i7-4770k)
 fail   -> PASS   (ro-bdw-i7-5557U)
 fail   -> PASS   (ro-bdw-i5-5250u)
 fail   -> PASS   (ro-skl3-i5-6260u)
Test kms_pipe_crc_basic:
 Subgroup suspend-read-crc-pipe-b:
 pass   -> DMESG-WARN (ro-bdw-i7-5600u)



https://bugs.freedesktop.org/show_bug.cgi?id=94992

[  522.498109] WARNING: CPU: 3 PID: 7786 at 
drivers/gpu/drm/i915/intel_display.c:13657 
intel_atomic_commit_tail+0x10fe/0x1110 [i915]

[  522.498110] pipe A vblank wait timed out


 dmesg-warn -> SKIP   (ro-bdw-i7-5557U)
 Subgroup suspend-read-crc-pipe-c:
 skip   -> DMESG-WARN (ro-bdw-i5-5250u)


https://bugs.freedesktop.org/show_bug.cgi?id=96614

[ 482.345981] [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* 
failed to enable link training
[ 482.431185] [drm:intel_dp_start_link_train [i915]] *ERROR* failed to 
start channel equalization




fi-hsw-i7-4770k  total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22
fi-skl-i5-6260u  total:244  pass:224  dwarn:4   dfail:0   fail:2   skip:14
fi-skl-i7-6700k  total:244  pass:208  dwarn:4   dfail:2   fail:2   skip:28
fi-snb-i7-2600   total:244  pass:202  dwarn:0   dfail:0   fail:0   skip:42
ro-bdw-i5-5250u  total:240  pass:219  dwarn:2   dfail:0   fail:1   skip:18
ro-bdw-i7-5557U  total:240  pass:220  dwarn:1   dfail:0   fail:0   skip:19
ro-bdw-i7-5600u  total:240  pass:206  dwarn:1   dfail:0   fail:1   skip:32
ro-bsw-n3050 total:240  pass:194  dwarn:0   dfail:0   fail:4   skip:42
ro-byt-n2820 total:240  pass:197  dwarn:0   dfail:0   fail:3   skip:40
ro-hsw-i3-4010u  total:240  pass:214  dwarn:0   dfail:0   fail:0   skip:26
ro-hsw-i7-4770r  total:240  pass:214  dwarn:0   dfail:0   fail:0   skip:26
ro-ilk1-i5-650   total:235  pass:173  dwarn:0   dfail:0   fail:2   skip:60
ro-ivb-i7-3770   total:240  pass:205  dwarn:0   dfail:0   fail:0   skip:35
ro-ivb2-i7-3770  total:240  pass:209  dwarn:0   dfail:0   fail:0   skip:31
ro-skl3-i5-6260u total:240  pass:223  dwarn:0   dfail:0   fail:3   skip:14

Results at /archive/results/CI_IGT_test/RO_Patchwork_1824/

3aec82c drm-intel-nightly: 2016y-08m-10d-15h-08m-03s UTC integration manifest
e3c7d5e drm/i915/guc: Consolidate firmware major-minor to one place


Merged to dinq, thanks for the review!

Regards,

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

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Store number of active engines in device info

[Tvrtko Ursulin]

On 10/08/16 18:27, Patchwork wrote:

== Series Details ==

Series: drm/i915: Store number of active engines in device info
URL   : https://patchwork.freedesktop.org/series/10921/
State : failure

== Summary ==

Series 10921v1 drm/i915: Store number of active engines in device info
http://patchwork.freedesktop.org/api/1.0/series/10921/revisions/1/mbox

Test kms_cursor_legacy:
 Subgroup basic-cursor-vs-flip-varying-size:
 fail   -> PASS   (ro-ilk1-i5-650)
 Subgroup basic-flip-vs-cursor-legacy:
 fail   -> PASS   (ro-skl3-i5-6260u)
 fail   -> PASS   (ro-bdw-i7-5557U)
 Subgroup basic-flip-vs-cursor-varying-size:
 fail   -> PASS   (ro-bdw-i5-5250u)
Test kms_pipe_crc_basic:
 Subgroup nonblocking-crc-pipe-b-frame-sequence:
 pass   -> FAIL   (ro-bdw-i7-5600u)


(kms_pipe_crc_basic:8255) CRITICAL: Failed assertion: crcs[j].frame + 1 
== crcs[j + 1].frame


Some modesetting problem, no idea, raised a new bug:

https://bugs.freedesktop.org/show_bug.cgi?id=97294


 Subgroup suspend-read-crc-pipe-b:
 dmesg-warn -> SKIP   (ro-bdw-i7-5557U)
 Subgroup suspend-read-crc-pipe-c:
 skip   -> DMESG-WARN (ro-bdw-i5-5250u)



https://bugs.freedesktop.org/show_bug.cgi?id=96614

[  482.345981] [drm:intel_dp_link_training_clock_recovery [i915]] 
*ERROR* failed to enable link training
[  482.431185] [drm:intel_dp_start_link_train [i915]] *ERROR* failed to 
start channel equalization


ro-bdw-i5-5250u  total:240  pass:219  dwarn:2   dfail:0   fail:1   skip:18
ro-bdw-i7-5557U  total:240  pass:220  dwarn:1   dfail:0   fail:0   skip:19
ro-bdw-i7-5600u  total:240  pass:206  dwarn:0   dfail:0   fail:2   skip:32
ro-bsw-n3050 total:240  pass:194  dwarn:0   dfail:0   fail:4   skip:42
ro-byt-n2820 total:240  pass:197  dwarn:0   dfail:0   fail:3   skip:40
ro-hsw-i3-4010u  total:240  pass:214  dwarn:0   dfail:0   fail:0   skip:26
ro-hsw-i7-4770r  total:240  pass:214  dwarn:0   dfail:0   fail:0   skip:26
ro-ilk1-i5-650   total:235  pass:174  dwarn:0   dfail:0   fail:1   skip:60
ro-ivb-i7-3770   total:240  pass:205  dwarn:0   dfail:0   fail:0   skip:35
ro-ivb2-i7-3770  total:240  pass:209  dwarn:0   dfail:0   fail:0   skip:31
ro-skl3-i5-6260u total:240  pass:223  dwarn:0   dfail:0   fail:3   skip:14

Results at /archive/results/CI_IGT_test/RO_Patchwork_1825/

3aec82c drm-intel-nightly: 2016y-08m-10d-15h-08m-03s UTC integration manifest
11c946d drm/i915: Store number of active engines in device info


Merged to dinq, thanks for the review!

Regards,

Tvrtko


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

[Intel-gfx] [PATCH 2/2] locking/barriers: suppress sparse warnings in lockless_dereference()

[Johannes Berg]

From: Johannes Berg 

After Peter's commit (see below) we get a lot of sparse warnings
(one for every rcu_dereference, and more) since the expression
here is assigning to the wrong address space.

Instead of validating that 'p' is a pointer this way, instead make
it fail compilation when it's not by using sizeof(*(p)). This will
not cause any sparse warnings (tested, likely since the address
space is irrelevant for sizeof), and will fail compilation when
'p' isn't a pointer type.

Fixes: 331b6d8c7afc ("locking/barriers: Validate lockless_dereference() is used 
on a pointer type")
Signed-off-by: Johannes Berg 
---
 include/linux/compiler.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 1bb954842725..436aa4e42221 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -527,13 +527,13 @@ static __always_inline void __write_once_size(volatile 
void *p, void *res, int s
  * object's lifetime is managed by something other than RCU.  That
  * "something other" might be reference counting or simple immortality.
  *
- * The seemingly unused void * variable is to validate @p is indeed a pointer
- * type. All pointer types silently cast to void *.
+ * The seemingly unused size_t variable is to validate @p is indeed a pointer
+ * type by making sure it can be dereferenced.
  */
 #define lockless_dereference(p) \
 ({ \
typeof(p) _p1 = READ_ONCE(p); \
-   __maybe_unused const void * const _p2 = _p1; \
+   size_t __maybe_unused __size_of_ptr = sizeof(*(p)); \
smp_read_barrier_depends(); /* Dependency order vs. p above. */ \
(_p1); \
 })
-- 
2.8.1

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