Re: [Intel-gfx] [PATCH RFC v3] drm: Add a new connector atomic property for link status

[Daniel Vetter]

On Wed, Nov 23, 2016 at 11:28:21PM -0800, Manasi Navare wrote:
> This is RFC patch for adding a connector link-status property
> and making it atomic by adding it to the drm_connector_state.
> This is to make sure its wired properly in drm_atomic_connector_set_property
> and drm_atomic_connector_get_property functions.
> 
> v3:
> * Fixed a build error (Jani Saarinen)
> v2:
> * Removed connector->link_status (Daniel Vetter)
> * Set connector->state->link_status in 
> drm_mode_connector_set_link_status_property
> (Daniel Vetter)
> * Set the connector_changed flag to true if connector->state->link_status 
> changed.
> * Reset link_status to GOOD in update_output_state (Daniel Vetter)
> * Never allow userspace to set link status from Good To Bad (Daniel Vetter)
> 
> Cc: Jani Nikula 
> Cc: Daniel Vetter 
> Cc: Ville Syrjala 
> Cc: Chris Wilson 
> Cc: Sean Paul 

You lost all the acked-by from AMD about the link-status property. We need
those.

> Signed-off-by: Manasi Navare 

Yeah I think this should work, but obviously testing has the final say.
Some nitpicks below, then it's r-b: me. But I think we also need to polish
the kernel-doc a bit more to address Sean Paul's questions.
-Daniel

> ---
>  drivers/gpu/drm/drm_atomic.c| 10 ++
>  drivers/gpu/drm/drm_atomic_helper.c |  8 +
>  drivers/gpu/drm/drm_connector.c | 61 
> -
>  include/drm/drm_connector.h | 18 ++-
>  include/drm/drm_mode_config.h   |  5 +++
>  include/uapi/drm/drm_mode.h |  4 +++
>  6 files changed, 104 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 89737e4..990f013 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1087,6 +1087,14 @@ int drm_atomic_connector_set_property(struct 
> drm_connector *connector,
>* now?) atomic writes to DPMS property:
>*/
>   return -EINVAL;
> + } else if (property == config->link_status_property) {
> + /* Never downgrade from GOOD to BAD on userspace's request here,
> +  * only hw issues can do that.
> +  */
> + if (state->link_status == DRM_LINK_STATUS_GOOD)
> + return 0;
> + state->link_status = val;
> + return 0;
>   } else if (connector->funcs->atomic_set_property) {
>   return connector->funcs->atomic_set_property(connector,
>   state, property, val);
> @@ -1135,6 +1143,8 @@ static void drm_atomic_connector_print_state(struct 
> drm_printer *p,
>   *val = (state->crtc) ? state->crtc->base.id : 0;
>   } else if (property == config->dpms_property) {
>   *val = connector->dpms;
> + } else if (property == config->link_status_property) {
> + *val = state->link_status;
>   } else if (connector->funcs->atomic_get_property) {
>   return connector->funcs->atomic_get_property(connector,
>   state, property, val);
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 494680c..962ed66 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -519,6 +519,13 @@ static int handle_conflicting_encoders(struct 
> drm_atomic_state *state,
>  connector_state);
>   if (ret)
>   return ret;
> + if (connector->state->crtc) {
> + crtc_state = drm_atomic_get_existing_crtc_state(state,
> + 
> connector->state->crtc);
> + if (connector->state->link_status !=
> + connector_state->link_status)
> + crtc_state->connectors_changed = true;
> + }

Why hide this here in handle_conflicting_encoders? This is a bit
confusing. I'd move it into the connector loop in
drm_atomic_helper_check_modeset().
>   }
>  
>   /*
> @@ -2258,6 +2265,7 @@ static int update_output_state(struct drm_atomic_state 
> *state,
>   NULL);
>   if (ret)
>   return ret;
> + conn_state->link_status = DRM_LINK_STATUS_GOOD;
>   }
>   }
>  
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 5a45262..cd53c39 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -243,6 +243,10 @@ int drm_connector_init(struct drm_device *dev,
>   drm_object_attach_property(>base,
> 

Re: [Intel-gfx] [PATCH] drm/i915: Move the release of PT page to the upper caller

[Chris Wilson]

On Wed, Nov 23, 2016 at 07:43:21AM +, Tian, Kevin wrote:
> It's also the style how CPU page table is managed...

But it is not the style of how the GPU page table behaves, which is what
the code expects. My only concern here is if the fact that the page is
not idle has further rammifactions.
-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] [PATCH RFC v3] drm: Add a new connector atomic property for link status

[Manasi Navare]

This is RFC patch for adding a connector link-status property
and making it atomic by adding it to the drm_connector_state.
This is to make sure its wired properly in drm_atomic_connector_set_property
and drm_atomic_connector_get_property functions.

v3:
* Fixed a build error (Jani Saarinen)
v2:
* Removed connector->link_status (Daniel Vetter)
* Set connector->state->link_status in 
drm_mode_connector_set_link_status_property
(Daniel Vetter)
* Set the connector_changed flag to true if connector->state->link_status 
changed.
* Reset link_status to GOOD in update_output_state (Daniel Vetter)
* Never allow userspace to set link status from Good To Bad (Daniel Vetter)

Cc: Jani Nikula 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Cc: Chris Wilson 
Cc: Sean Paul 
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/drm_atomic.c| 10 ++
 drivers/gpu/drm/drm_atomic_helper.c |  8 +
 drivers/gpu/drm/drm_connector.c | 61 -
 include/drm/drm_connector.h | 18 ++-
 include/drm/drm_mode_config.h   |  5 +++
 include/uapi/drm/drm_mode.h |  4 +++
 6 files changed, 104 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 89737e4..990f013 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1087,6 +1087,14 @@ int drm_atomic_connector_set_property(struct 
drm_connector *connector,
 * now?) atomic writes to DPMS property:
 */
return -EINVAL;
+   } else if (property == config->link_status_property) {
+   /* Never downgrade from GOOD to BAD on userspace's request here,
+* only hw issues can do that.
+*/
+   if (state->link_status == DRM_LINK_STATUS_GOOD)
+   return 0;
+   state->link_status = val;
+   return 0;
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(connector,
state, property, val);
@@ -1135,6 +1143,8 @@ static void drm_atomic_connector_print_state(struct 
drm_printer *p,
*val = (state->crtc) ? state->crtc->base.id : 0;
} else if (property == config->dpms_property) {
*val = connector->dpms;
+   } else if (property == config->link_status_property) {
+   *val = state->link_status;
} else if (connector->funcs->atomic_get_property) {
return connector->funcs->atomic_get_property(connector,
state, property, val);
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 494680c..962ed66 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -519,6 +519,13 @@ static int handle_conflicting_encoders(struct 
drm_atomic_state *state,
   connector_state);
if (ret)
return ret;
+   if (connector->state->crtc) {
+   crtc_state = drm_atomic_get_existing_crtc_state(state,
+   
connector->state->crtc);
+   if (connector->state->link_status !=
+   connector_state->link_status)
+   crtc_state->connectors_changed = true;
+   }
}
 
/*
@@ -2258,6 +2265,7 @@ static int update_output_state(struct drm_atomic_state 
*state,
NULL);
if (ret)
return ret;
+   conn_state->link_status = DRM_LINK_STATUS_GOOD;
}
}
 
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 5a45262..cd53c39 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -243,6 +243,10 @@ int drm_connector_init(struct drm_device *dev,
drm_object_attach_property(>base,
  config->dpms_property, 0);
 
+   drm_object_attach_property(>base,
+  config->link_status_property,
+  0);
+
if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
drm_object_attach_property(>base, 
config->prop_crtc_id, 0);
}
@@ -506,6 +510,12 @@ const char *drm_get_subpixel_order_name(enum 
subpixel_order order)
 };
 DRM_ENUM_NAME_FN(drm_get_dpms_name, drm_dpms_enum_list)
 
+static const struct drm_prop_enum_list drm_link_status_enum_list[] = {
+   { DRM_MODE_LINK_STATUS_GOOD, "Good" },
+   { DRM_MODE_LINK_STATUS_BAD, "Bad" 

Re: [Intel-gfx] [PATCH] drm/i915: Always load guc by default.

[Chris Wilson]

On Wed, Nov 23, 2016 at 04:52:38PM -0800, Anusha Srivatsa wrote:
> Remove the enable_guc_loading parameter. Load the GuC on
> plaforms that have GuC. All issues we found so far are related
> to GuC features like the command submission, but no bug is related
> to the guc loading itself.
> 
> This addresses the case when we need GuC loaded even with no GuC feature
> in use, like - GuC  authenticating HuC loading.

Why not just load the firmware if it may be used?
-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] [igvt-g-dev] [bug report] drm/i915/gvt: fix deadlock in workload_thread

[Zhang, Pei]

Thanks Dan for pointing this code error. Zhenyu, your change looks fine to me.

-Original Message-
From: Zhenyu Wang [mailto:zhen...@linux.intel.com] 
Sent: Thursday, November 24, 2016 10:41
To: Dan Carpenter 
Cc: Zhang, Pei ; intel-gfx@lists.freedesktop.org; 
igvt-g-...@lists.01.org
Subject: Re: [igvt-g-dev] [bug report] drm/i915/gvt: fix deadlock in 
workload_thread

On 2016.11.24 01:17:06 +0300, Dan Carpenter wrote:
> Hello Pei Zhang,
> 
> The patch 90d27a1b180e: "drm/i915/gvt: fix deadlock in 
> workload_thread" from Nov 14, 2016, leads to the following static 
> checker warning:
> 
>   drivers/gpu/drm/i915/gvt/scheduler.c:217 dispatch_workload()
>   warn: inconsistent returns 'mutex:_priv->drm.struct_mutex'.
> 
> drivers/gpu/drm/i915/gvt/scheduler.c
>161  static int dispatch_workload(struct intel_vgpu_workload *workload)
>162  {
>163  int ring_id = workload->ring_id;
>164  struct i915_gem_context *shadow_ctx = 
> workload->vgpu->shadow_ctx;
>165  struct drm_i915_private *dev_priv = 
> workload->vgpu->gvt->dev_priv;
>166  struct drm_i915_gem_request *rq;
>167  int ret;
>168  
>169  gvt_dbg_sched("ring id %d prepare to dispatch workload %p\n",
>170  ring_id, workload);
>171  
>172  shadow_ctx->desc_template = 
> workload->ctx_desc.addressing_mode <<
>173  GEN8_CTX_ADDRESSING_MODE_SHIFT;
>174  
>175  mutex_lock(_priv->drm.struct_mutex);
>176  
>177  rq = i915_gem_request_alloc(dev_priv->engine[ring_id], 
> shadow_ctx);
>178  if (IS_ERR(rq)) {
>179  gvt_err("fail to allocate gem request\n");
>180  workload->status = PTR_ERR(rq);
>181  return workload->status;
> 
> We're holding the lock here, which is obviously a bug.  But also 
> should we goto out?  I always thought that functions with an "out" 
> label were future proof?
>

Thanks, Dan. Yes, missed alloc failure path. How about below one? Pei, is it 
fine for you?

diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
b/drivers/gpu/drm/i915/gvt/scheduler.c
index f898df3..4db2422 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -177,8 +177,8 @@ static int dispatch_workload(struct intel_vgpu_workload 
*workload)
rq = i915_gem_request_alloc(dev_priv->engine[ring_id], shadow_ctx);
if (IS_ERR(rq)) {
gvt_err("fail to allocate gem request\n");
-   workload->status = PTR_ERR(rq);
-   return workload->status;
+   ret = PTR_ERR(rq);
+   goto out;
}
 
gvt_dbg_sched("ring id %d get i915 gem request %p\n", ring_id, rq); @@ 
-212,7 +212,8 @@ static int dispatch_workload(struct intel_vgpu_workload 
*workload)
if (ret)
workload->status = ret;
 
-   i915_add_request_no_flush(rq);
+   if (!IS_ERR_OR_NULL(rq))
+   i915_add_request_no_flush(rq);
mutex_unlock(_priv->drm.struct_mutex);
return ret;
 }
@@ -460,7 +461,8 @@ static int workload_thread(void *priv)
 
complete_current_workload(gvt, ring_id);
 
-   i915_gem_request_put(fetch_and_zero(>req));
+   if (workload->req)
+   i915_gem_request_put(fetch_and_zero(>req));
 
if (need_force_wake)
intel_uncore_forcewake_put(gvt->dev_priv,


--
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for GEN-9 Arbitrated Bandwidth WM WA's & IPC (rev2)

[Patchwork]

== Series Details ==

Series: GEN-9 Arbitrated Bandwidth WM WA's & IPC (rev2)
URL   : https://patchwork.freedesktop.org/series/15562/
State : success

== Summary ==

Series 15562v2 GEN-9 Arbitrated Bandwidth WM WA's & IPC
https://patchwork.freedesktop.org/api/1.0/series/15562/revisions/2/mbox/


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

a08f9fc55a649334a2788a804904d920f8b2fda2 drm-intel-nightly: 
2016y-11m-23d-20h-25m-10s UTC integration manifest
7ee0d75 drm/i915: Add intel_atomic_get_existing_crtc_state function
8472737 drm/i915/skl+: change WM calc to fixed point 16.16
bc8dd25 drm/i915/bxt: Enable IPC support
4a59efc drm/i915/kbl: IPC workaround for kabylake
e3fe641 drm/i915/bxt: IPC WA for Broxton
667f684 drm/i915/skl: Add variables to check x_tile and y_tile

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm: Add a new connector atomic property for link status (rev3)

[Patchwork]

== Series Details ==

Series: drm: Add a new connector atomic property for link status (rev3)
URL   : https://patchwork.freedesktop.org/series/15781/
State : failure

== Summary ==

  CC  drivers/acpi/acpica/utpredef.o
  CONMK   drivers/tty/vt/consolemap_deftbl.c
  CC  drivers/acpi/acpica/utownerid.o
  CC  drivers/acpi/acpica/utresrc.o
  CC  drivers/tty/vt/vt.o
  SHIPPED drivers/tty/vt/defkeymap.c
  CC  drivers/acpi/acpica/utstate.o
  CC  drivers/acpi/acpica/utstring.o
  CC  drivers/acpi/acpica/utstrtoul64.o
  CC  drivers/acpi/acpica/utxface.o
  CC  drivers/acpi/acpica/utxfinit.o
  CC  drivers/tty/vt/consolemap_deftbl.o
  CC  drivers/acpi/acpica/utxferror.o
  CC  drivers/acpi/acpica/utxfmutex.o
  CC  drivers/tty/vt/defkeymap.o
  LD  drivers/watchdog/watchdog.o
  LD  drivers/watchdog/built-in.o
  LD  kernel/sched/built-in.o
  LD [M]  drivers/misc/mei/mei-me.o
  LD  drivers/misc/built-in.o
  LD  kernel/built-in.o
  LD  drivers/input/mouse/psmouse.o
  LD [M]  drivers/ssb/ssb.o
  LD  drivers/input/mouse/built-in.o
  LD  drivers/input/built-in.o
  LD [M]  drivers/net/ethernet/broadcom/genet/genet.o
scripts/Makefile.build:544: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:544: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
make[1]: *** Waiting for unfinished jobs
  LD  drivers/video/fbdev/core/fb.o
  LD  drivers/pci/pcie/pcieportdrv.o
  LD  drivers/video/fbdev/core/built-in.o
  LD  drivers/acpi/acpica/acpi.o
  LD [M]  drivers/usb/serial/usbserial.o
  LD  drivers/pci/pcie/aer/aerdriver.o
  LD  drivers/pci/pcie/aer/built-in.o
  LD  drivers/pci/pcie/built-in.o
  LD  drivers/iommu/built-in.o
  LD  drivers/mmc/built-in.o
  LD  drivers/acpi/acpica/built-in.o
  LD  drivers/video/fbdev/built-in.o
  LD  drivers/usb/storage/usb-storage.o
  LD  drivers/acpi/built-in.o
  LD  drivers/scsi/scsi_mod.o
  LD  drivers/usb/storage/built-in.o
  LD  net/ipv6/ipv6.o
  LD  drivers/tty/serial/8250/8250.o
  LD  drivers/usb/gadget/udc/udc-core.o
  LD  drivers/usb/gadget/udc/built-in.o
  LD  net/ipv6/built-in.o
  LD  drivers/thermal/thermal_sys.o
  LD  drivers/thermal/built-in.o
  LD  drivers/pci/built-in.o
  LD  drivers/usb/gadget/libcomposite.o
  LD  drivers/usb/gadget/built-in.o
  AR  lib/lib.a
  EXPORTS lib/lib-ksyms.o
  LD  lib/built-in.o
  LD  drivers/spi/built-in.o
  LD [M]  drivers/net/ethernet/intel/e1000/e1000.o
  LD  drivers/scsi/sd_mod.o
  LD [M]  sound/pci/hda/snd-hda-codec-generic.o
  LD  drivers/scsi/built-in.o
  LD  sound/pci/built-in.o
  LD  sound/built-in.o
  LD  drivers/video/console/built-in.o
  LD  drivers/video/built-in.o
  LD  drivers/usb/core/usbcore.o
  LD  drivers/tty/serial/8250/8250_base.o
  LD  drivers/tty/serial/8250/built-in.o
  LD  drivers/usb/core/built-in.o
  CC  arch/x86/kernel/cpu/capflags.o
  LD  arch/x86/kernel/cpu/built-in.o
  LD  drivers/md/md-mod.o
  LD  fs/btrfs/btrfs.o
  LD  drivers/tty/serial/built-in.o
  LD  arch/x86/kernel/built-in.o
  LD  drivers/md/built-in.o
  LD [M]  drivers/net/ethernet/intel/igbvf/igbvf.o
  LD  fs/btrfs/built-in.o
  LD  arch/x86/built-in.o
  LD  drivers/tty/vt/built-in.o
  LD  drivers/tty/built-in.o
  LD  drivers/usb/host/xhci-hcd.o
  LD  net/ipv4/built-in.o
  LD  drivers/usb/host/built-in.o
  LD [M]  drivers/net/ethernet/intel/igb/igb.o
  LD  drivers/usb/built-in.o
  LD  fs/ext4/ext4.o
  LD  fs/ext4/built-in.o
  LD  fs/built-in.o
  LD [M]  drivers/net/ethernet/intel/e1000e/e1000e.o
  LD  net/core/built-in.o
  LD  net/built-in.o
  LD  drivers/net/ethernet/built-in.o
  LD  drivers/net/built-in.o
Makefile:986: recipe for target 'drivers' failed
make: *** [drivers] Error 2

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

[Intel-gfx] [PATCH v6 4/8] drm/i915/bxt: Enable IPC support

[Mahesh Kumar]

This patch adds IPC support for platforms. This patch enables IPC
only for BXT/KBL platform as for SKL recommendation is to keep is disabled.
IPC (Isochronous Priority Control) is the hardware feature, which
dynamically controles the memory read priority of Display.

When IPC is enabled, plane read requests are sent at high priority until
filling above the transition watermark, then the requests are sent at
lower priority until dropping below the level 0 watermark.
The lower priority requests allow other memory clients to have better
memory access. When IPC is disabled, all plane read requests are sent at
high priority.

Changes since V1:
 - Remove commandline parameter to disable ipc
 - Address Paulo's comments
Changes since V2:
 - Address review comments
 - Set ipc_enabled flag
Changes since V3:
 - move ipc_enabled flag assignment inside intel_ipc_enable function

Signed-off-by: Mahesh Kumar 
---
 drivers/gpu/drm/i915/i915_drv.c  |  2 +-
 drivers/gpu/drm/i915/i915_reg.h  |  1 +
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 drivers/gpu/drm/i915/intel_pm.c  | 16 
 4 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 1b0a589..b83e84b 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1243,7 +1243,7 @@ int i915_driver_load(struct pci_dev *pdev, const struct 
pci_device_id *ent)
 
intel_runtime_pm_enable(dev_priv);
 
-   dev_priv->ipc_enabled = false;
+   intel_enable_ipc(dev_priv);
 
/* Everything is in place, we can now relax! */
DRM_INFO("Initialized %s %d.%d.%d %s for %s on minor %d\n",
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c70c07a..300418a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6076,6 +6076,7 @@ enum {
 #define  DISP_FBC_WM_DIS   (1<<15)
 #define DISP_ARB_CTL2  _MMIO(0x45004)
 #define  DISP_DATA_PARTITION_5_6   (1<<6)
+#define  DISP_IPC_ENABLE   (1<<3)
 #define DBUF_CTL   _MMIO(0x45008)
 #define  DBUF_POWER_REQUEST(1<<31)
 #define  DBUF_POWER_STATE  (1<<30)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index cd132c2..ad542a2 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1745,6 +1745,7 @@ bool skl_ddb_allocation_overlaps(const struct 
skl_ddb_entry **entries,
 uint32_t ilk_pipe_pixel_rate(const struct intel_crtc_state *pipe_config);
 bool ilk_disable_lp_wm(struct drm_device *dev);
 int sanitize_rc6_option(struct drm_i915_private *dev_priv, int enable_rc6);
+void intel_enable_ipc(struct drm_i915_private *dev_priv);
 static inline int intel_enable_rc6(void)
 {
return i915.enable_rc6;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 33d22cc..df6d231 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4682,6 +4682,22 @@ void intel_update_watermarks(struct intel_crtc *crtc)
dev_priv->display.update_wm(crtc);
 }
 
+void intel_enable_ipc(struct drm_i915_private *dev_priv)
+{
+   u32 val;
+
+   dev_priv->ipc_enabled = false;
+   if (!(IS_BROXTON(dev_priv) || IS_KABYLAKE(dev_priv)))
+   return;
+
+   val = I915_READ(DISP_ARB_CTL2);
+
+   val |= DISP_IPC_ENABLE;
+
+   I915_WRITE(DISP_ARB_CTL2, val);
+   dev_priv->ipc_enabled = true;
+}
+
 /*
  * Lock protecting IPS related data structures
  */
-- 
2.10.1

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

[Intel-gfx] [PATCH v6 2/8] drm/i915/bxt: IPC WA for Broxton

[Mahesh Kumar]

If IPC is enabled in BXT, display underruns are observed.
WA: The Line Time programmed in the WM_LINETIME register should be
half of the actual calculated Line Time.

Programmed Line Time = 1/2*Calculated Line Time

Signed-off-by: Mahesh Kumar 
Reviewed-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_drv.c |  2 ++
 drivers/gpu/drm/i915/i915_drv.h |  2 ++
 drivers/gpu/drm/i915/intel_pm.c | 11 +--
 3 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 445fec9..1b0a589 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1243,6 +1243,8 @@ int i915_driver_load(struct pci_dev *pdev, const struct 
pci_device_id *ent)
 
intel_runtime_pm_enable(dev_priv);
 
+   dev_priv->ipc_enabled = false;
+
/* Everything is in place, we can now relax! */
DRM_INFO("Initialized %s %d.%d.%d %s for %s on minor %d\n",
 driver.name, driver.major, driver.minor, driver.patchlevel,
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 63c0ea0..6691a4e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2128,6 +2128,8 @@ struct drm_i915_private {
/* perform PHY state sanity checks? */
bool chv_phy_assert[2];
 
+   bool ipc_enabled;
+
/* Used to save the pipe-to-encoder mapping for audio */
struct intel_encoder *av_enc_map[I915_MAX_PIPES];
 
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 8908736..7090a7c 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3769,7 +3769,10 @@ skl_compute_wm_level(const struct drm_i915_private 
*dev_priv,
 static uint32_t
 skl_compute_linetime_wm(struct intel_crtc_state *cstate)
 {
+   struct drm_atomic_state *state = cstate->base.state;
+   struct drm_i915_private *dev_priv = to_i915(state->dev);
uint32_t pixel_rate;
+   uint32_t linetime_wm;
 
if (!cstate->base.active)
return 0;
@@ -3779,8 +3782,12 @@ skl_compute_linetime_wm(struct intel_crtc_state *cstate)
if (WARN_ON(pixel_rate == 0))
return 0;
 
-   return DIV_ROUND_UP(8 * cstate->base.adjusted_mode.crtc_htotal * 1000,
-   pixel_rate);
+   linetime_wm = DIV_ROUND_UP(8 * cstate->base.adjusted_mode.crtc_htotal *
+   1000, pixel_rate);
+   if (IS_BROXTON(dev_priv) && dev_priv->ipc_enabled)
+   linetime_wm = DIV_ROUND_UP(linetime_wm, 2);
+
+   return linetime_wm;
 }
 
 static void skl_compute_transition_wm(struct intel_crtc_state *cstate,
-- 
2.10.1

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

[Intel-gfx] [PATCH v6 5/8] drm/i915/skl+: change WM calc to fixed point 16.16

[Mahesh Kumar]

This patch changes Watermak calculation to fixed point calculation.
Problem with current calculation is during plane_blocks_per_line
calculation we divide intermediate blocks with min_scanlines and
takes floor of the result because of integer operation.
hence we end-up assigning less blocks than required. Which leads to
flickers.

Changes since V1:
 - Add fixed point data type as per Paulo's review
Changes since V1:
 - use fixed_point instead of fp_16_16

Signed-off-by: Mahesh Kumar 
---
 drivers/gpu/drm/i915/i915_drv.h | 84 +
 drivers/gpu/drm/i915/intel_pm.c | 69 +++--
 2 files changed, 124 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6691a4e..e332f04 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -119,6 +119,90 @@ bool __i915_inject_load_failure(const char *func, int 
line);
 #define i915_inject_load_failure() \
__i915_inject_load_failure(__func__, __LINE__)
 
+typedef struct {
+   uint32_t val;
+} uint_fixed_16_16_t;
+
+#define FP_16_16_MAX ({ \
+   uint_fixed_16_16_t fp; \
+   fp.val = UINT_MAX; \
+   fp; \
+})
+
+static inline uint_fixed_16_16_t u32_to_fixed_point(uint32_t val)
+{
+   uint_fixed_16_16_t fp;
+
+   WARN_ON(val >> 16);
+
+   fp.val = val << 16;
+   return fp;
+}
+
+static inline uint32_t fixed_point_to_u32_round_up(uint_fixed_16_16_t fp)
+{
+   return DIV_ROUND_UP(fp.val, 1 << 16);
+}
+
+static inline uint32_t fixed_point_to_u32(uint_fixed_16_16_t fp)
+{
+   return (fp.val / (1 << 16));
+}
+
+static inline uint_fixed_16_16_t min_fixed_point(uint_fixed_16_16_t min1,
+   uint_fixed_16_16_t min2)
+{
+   uint_fixed_16_16_t min;
+
+   min.val = min(min1.val, min2.val);
+   return min;
+}
+
+static inline uint_fixed_16_16_t max_fixed_point(uint_fixed_16_16_t max1,
+   uint_fixed_16_16_t max2)
+{
+   uint_fixed_16_16_t max;
+
+   max.val = max(max1.val, max2.val);
+   return max;
+}
+
+static inline uint_fixed_16_16_t fixed_point_div_round_up(uint32_t val,
+   uint32_t d)
+{
+   uint_fixed_16_16_t fp, res;
+
+   fp = u32_to_fixed_point(val);
+   res.val = DIV_ROUND_UP(fp.val, d);
+   return res;
+}
+
+static inline uint_fixed_16_16_t fixed_point_div_round_up_u64(uint32_t val,
+   uint32_t d)
+{
+   uint_fixed_16_16_t res;
+   uint64_t interm_val;
+
+   interm_val = (uint64_t)val << 16;
+   interm_val = DIV_ROUND_UP_ULL(interm_val, d);
+   WARN_ON(interm_val >> 32);
+   res.val = (uint32_t) interm_val;
+
+   return res;
+}
+
+static inline uint_fixed_16_16_t mul_fixed_point_u32(uint32_t val,
+   uint_fixed_16_16_t mul)
+{
+   uint64_t intermediate_val;
+   uint_fixed_16_16_t fp;
+
+   intermediate_val = (uint64_t) val * mul.val;
+   WARN_ON(intermediate_val >> 32);
+   fp.val = (uint32_t) intermediate_val;
+   return fp;
+}
+
 static inline const char *yesno(bool v)
 {
return v ? "yes" : "no";
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index df6d231..3e2dd8f 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3516,32 +3516,35 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
  * should allow pixel_rate up to ~2 GHz which seems sufficient since max
  * 2xcdclk is 1350 MHz and the pixel rate should never exceed that.
 */
-static uint32_t skl_wm_method1(uint32_t pixel_rate, uint8_t cpp, uint32_t 
latency)
+static uint_fixed_16_16_t skl_wm_method1(uint32_t pixel_rate, uint8_t cpp,
+uint32_t latency)
 {
-   uint32_t wm_intermediate_val, ret;
+   uint32_t wm_intermediate_val;
+   uint_fixed_16_16_t ret;
 
if (latency == 0)
-   return UINT_MAX;
-
-   wm_intermediate_val = latency * pixel_rate * cpp / 512;
-   ret = DIV_ROUND_UP(wm_intermediate_val, 1000);
+   return FP_16_16_MAX;
 
+   wm_intermediate_val = latency * pixel_rate * cpp;
+   ret = fixed_point_div_round_up_u64(wm_intermediate_val, 1000 * 512);
return ret;
 }
 
-static uint32_t skl_wm_method2(uint32_t pixel_rate, uint32_t pipe_htotal,
-  uint32_t latency, uint32_t plane_blocks_per_line)
+static uint_fixed_16_16_t skl_wm_method2(uint32_t pixel_rate,
+   uint32_t pipe_htotal,
+   uint32_t latency,
+   uint_fixed_16_16_t plane_blocks_per_line)
 {
-   uint32_t ret;
uint32_t wm_intermediate_val;
+   uint_fixed_16_16_t ret;
 
if (latency == 0)
-   return UINT_MAX;

[Intel-gfx] [PATCH v6 6/8] drm/i915: Add intel_atomic_get_existing_crtc_state function

[Mahesh Kumar]

This patch Adds a function to extract intel_crtc_state from the
atomic_state, if not available it returns NULL.

Signed-off-by: Mahesh Kumar 
Reviewed-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_drv.h | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index ad542a2..db75773 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1794,6 +1794,20 @@ intel_atomic_get_crtc_state(struct drm_atomic_state 
*state,
return to_intel_crtc_state(crtc_state);
 }
 
+static inline struct intel_crtc_state *
+intel_atomic_get_existing_crtc_state(struct drm_atomic_state *state,
+ struct intel_crtc *crtc)
+{
+   struct drm_crtc_state *crtc_state;
+
+   crtc_state = drm_atomic_get_existing_crtc_state(state, >base);
+
+   if (crtc_state)
+   return to_intel_crtc_state(crtc_state);
+   else
+   return NULL;
+}
+
 static inline struct intel_plane_state *
 intel_atomic_get_existing_plane_state(struct drm_atomic_state *state,
  struct intel_plane *plane)
-- 
2.10.1

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

[Intel-gfx] [PATCH v6 8/8] drm/i915/gen9: WM memory bandwidth related workaround

[Mahesh Kumar]

This patch implemnets Workariunds related to display arbitrated memory
bandwidth. These WA are applicabe for all gen-9 based platforms.

Changes since v1:
 - Rebase on top of Paulo's patch series
Changes since v2:
 - Address review comments
 - Rebase/rework as per other patch changes in series

Signed-off-by: Mahesh Kumar 
---
 drivers/gpu/drm/i915/i915_drv.h |   9 +++
 drivers/gpu/drm/i915/intel_pm.c | 149 +---
 2 files changed, 149 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4e2f17f..2b673c6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1193,6 +1193,13 @@ enum intel_sbi_destination {
SBI_MPHY,
 };
 
+/* SKL+ Watermark arbitrated display bandwidth Workarounds */
+enum watermark_memory_wa {
+   WATERMARK_WA_NONE,
+   WATERMARK_WA_X_TILED,
+   WATERMARK_WA_Y_TILED,
+};
+
 #define QUIRK_PIPEA_FORCE (1<<0)
 #define QUIRK_LVDS_SSC_DISABLE (1<<1)
 #define QUIRK_INVERT_BRIGHTNESS (1<<2)
@@ -1764,6 +1771,8 @@ struct skl_ddb_allocation {
 
 struct skl_wm_values {
unsigned dirty_pipes;
+   /* any WaterMark memory workaround Required */
+   enum watermark_memory_wa mem_wa;
struct skl_ddb_allocation ddb;
 };
 
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 3e2dd8f..547bbda 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2889,11 +2889,7 @@ skl_wm_plane_id(const struct intel_plane *plane)
}
 }
 
-/*
- * FIXME: We still don't have the proper code detect if we need to apply the 
WA,
- * so assume we'll always need it in order to avoid underruns.
- */
-static bool skl_needs_memory_bw_wa(struct intel_atomic_state *state)
+static bool intel_needs_memory_bw_wa(struct intel_atomic_state *state)
 {
struct drm_i915_private *dev_priv = to_i915(state->base.dev);
 
@@ -3067,7 +3063,7 @@ bool intel_can_enable_sagv(struct drm_atomic_state *state)
 
latency = dev_priv->wm.skl_latency[level];
 
-   if (skl_needs_memory_bw_wa(intel_state) &&
+   if (intel_needs_memory_bw_wa(intel_state) &&
plane->base.state->fb->modifier ==
I915_FORMAT_MOD_X_TILED)
latency += 15;
@@ -3597,7 +3593,7 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
uint32_t y_min_scanlines;
struct intel_atomic_state *state =
to_intel_atomic_state(cstate->base.state);
-   bool apply_memory_bw_wa = skl_needs_memory_bw_wa(state);
+   enum watermark_memory_wa mem_wa;
bool y_tiled, x_tiled;
 
if (latency == 0 || !cstate->base.active || 
!intel_pstate->base.visible) {
@@ -3613,7 +3609,8 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
if (IS_KABYLAKE(dev_priv) && dev_priv->ipc_enabled)
latency += 4;
 
-   if (apply_memory_bw_wa && x_tiled)
+   mem_wa = state->wm_results.mem_wa;
+   if (mem_wa != WATERMARK_WA_NONE && x_tiled)
latency += 15;
 
width = drm_rect_width(_pstate->base.src) >> 16;
@@ -3648,7 +3645,7 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
y_min_scanlines = 4;
}
 
-   if (apply_memory_bw_wa)
+   if (mem_wa == WATERMARK_WA_Y_TILED)
y_min_scanlines *= 2;
 
plane_bytes_per_line = width * cpp;
@@ -4077,6 +4074,15 @@ skl_compute_ddb(struct drm_atomic_state *state)
}
 
/*
+* If Watermark workaround is changed we need to recalculate
+* watermark values for all active pipes
+*/
+   if (intel_state->wm_results.mem_wa != dev_priv->wm.skl_hw.mem_wa) {
+   realloc_pipes = ~0;
+   intel_state->wm_results.dirty_pipes = ~0;
+   }
+
+   /*
 * We're not recomputing for the pipes not included in the commit, so
 * make sure we start with the current state.
 */
@@ -4102,6 +4108,129 @@ skl_compute_ddb(struct drm_atomic_state *state)
 }
 
 static void
+skl_compute_memory_bandwidth_wm_wa(struct drm_atomic_state *state)
+{
+   struct drm_device *dev = state->dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   struct intel_crtc *intel_crtc;
+   struct intel_plane_state *intel_pstate;
+   struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
+   struct memdev_info *memdev_info = _priv->memdev_info;
+   int num_active_pipes;
+   uint32_t max_pipe_bw_kbps, total_pipe_bw_kbps;
+   int display_bw_percentage;
+   bool y_tile_enabled = false;
+
+   if (!intel_needs_memory_bw_wa(intel_state)) {
+   intel_state->wm_results.mem_wa = WATERMARK_WA_NONE;
+   return;
+   }
+
+   if (!memdev_info->valid)
+   goto exit;
+
+   

[Intel-gfx] [PATCH v6 3/8] drm/i915/kbl: IPC workaround for kabylake

[Mahesh Kumar]

IPC (Isoch Priority Control) may cause underflows.

KBL WA: When IPC is enabled, watermark latency values must be increased
by 4us across all levels. This brings level 0 up to 6us.

Signed-off-by: Mahesh Kumar 
Reviewed-by: Paulo Zanoni 
---
 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 7090a7c..33d22cc 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3603,6 +3603,10 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
fb->modifier == I915_FORMAT_MOD_Yf_TILED;
x_tiled = fb->modifier == I915_FORMAT_MOD_X_TILED;
 
+   /* IPC WA for kabylake */
+   if (IS_KABYLAKE(dev_priv) && dev_priv->ipc_enabled)
+   latency += 4;
+
if (apply_memory_bw_wa && x_tiled)
latency += 15;
 
-- 
2.10.1

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

[Intel-gfx] [PATCH v6 1/8] drm/i915/skl: Add variables to check x_tile and y_tile

[Mahesh Kumar]

This patch adds variable to check for X_tiled & y_tiled planes, instead
of always checking against framebuffer-modifiers.

Changes:
 - Created separate patch as per Paulo's comment
 - Added x_tiled variable as well
Changes since V2:
 - Incorporate Paulo's comments
 - Rebase

Signed-off-by: Mahesh Kumar 
Reviewed-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_pm.c | 22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index e54708d..8908736 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3592,13 +3592,18 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
struct intel_atomic_state *state =
to_intel_atomic_state(cstate->base.state);
bool apply_memory_bw_wa = skl_needs_memory_bw_wa(state);
+   bool y_tiled, x_tiled;
 
if (latency == 0 || !cstate->base.active || 
!intel_pstate->base.visible) {
*enabled = false;
return 0;
}
 
-   if (apply_memory_bw_wa && fb->modifier == I915_FORMAT_MOD_X_TILED)
+   y_tiled = fb->modifier == I915_FORMAT_MOD_Y_TILED ||
+   fb->modifier == I915_FORMAT_MOD_Yf_TILED;
+   x_tiled = fb->modifier == I915_FORMAT_MOD_X_TILED;
+
+   if (apply_memory_bw_wa && x_tiled)
latency += 15;
 
width = drm_rect_width(_pstate->base.src) >> 16;
@@ -3637,16 +3642,15 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
y_min_scanlines *= 2;
 
plane_bytes_per_line = width * cpp;
-   if (fb->modifier == I915_FORMAT_MOD_Y_TILED ||
-   fb->modifier == I915_FORMAT_MOD_Yf_TILED) {
+   if (y_tiled) {
plane_blocks_per_line =
  DIV_ROUND_UP(plane_bytes_per_line * y_min_scanlines, 512);
plane_blocks_per_line /= y_min_scanlines;
-   } else if (fb->modifier == DRM_FORMAT_MOD_NONE) {
+   } else if (x_tiled) {
+   plane_blocks_per_line = DIV_ROUND_UP(plane_bytes_per_line, 512);
+   } else {
plane_blocks_per_line = DIV_ROUND_UP(plane_bytes_per_line, 512)
+ 1;
-   } else {
-   plane_blocks_per_line = DIV_ROUND_UP(plane_bytes_per_line, 512);
}
 
method1 = skl_wm_method1(plane_pixel_rate, cpp, latency);
@@ -3657,8 +3661,7 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
 
y_tile_minimum = plane_blocks_per_line * y_min_scanlines;
 
-   if (fb->modifier == I915_FORMAT_MOD_Y_TILED ||
-   fb->modifier == I915_FORMAT_MOD_Yf_TILED) {
+   if (y_tiled) {
selected_result = max(method2, y_tile_minimum);
} else {
if ((cpp * cstate->base.adjusted_mode.crtc_htotal / 512 < 1) &&
@@ -3674,8 +3677,7 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
res_lines = DIV_ROUND_UP(selected_result, plane_blocks_per_line);
 
if (level >= 1 && level <= 7) {
-   if (fb->modifier == I915_FORMAT_MOD_Y_TILED ||
-   fb->modifier == I915_FORMAT_MOD_Yf_TILED) {
+   if (y_tiled) {
res_blocks += y_tile_minimum;
res_lines += y_min_scanlines;
} else {
-- 
2.10.1

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

[Intel-gfx] [PATCH v6 7/8] drm/i915: Decode system memory bandwidth

[Mahesh Kumar]

This patch adds support to decode system memory bandwidth
which will be used for arbitrated display memory percentage
calculation in GEN9 based system.

Changes from v1:
 - Address comments from Paulo
 - implement decode function for SKL/KBL also
Changes from v2:
 - Rewrite the code as per HW team inputs
 - Addresses review comments

Signed-off-by: Mahesh Kumar 
---
 drivers/gpu/drm/i915/i915_drv.c | 173 
 drivers/gpu/drm/i915/i915_drv.h |  12 +++
 drivers/gpu/drm/i915/i915_reg.h |  37 +
 3 files changed, 222 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index b83e84b..ded1d05 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -976,6 +976,173 @@ static void intel_sanitize_options(struct 
drm_i915_private *dev_priv)
DRM_DEBUG_DRIVER("use GPU sempahores? %s\n", yesno(i915.semaphores));
 }
 
+static inline enum rank skl_memdev_get_channel_rank(uint32_t val)
+{
+   uint8_t l_rank, s_rank;
+   uint8_t l_size, s_size;
+   enum rank ch_rank = DRAM_RANK_SINGLE;
+
+   l_size = (val >> SKL_DRAM_SIZE_L_SHIFT) & SKL_DRAM_SIZE_MASK;
+   s_size = (val >> SKL_DRAM_SIZE_S_SHIFT) & SKL_DRAM_SIZE_MASK;
+   l_rank = (val >> SKL_DRAM_RANK_L_SHIFT) & SKL_DRAM_RANK_MASK;
+   s_rank = (val >> SKL_DRAM_RANK_S_SHIFT) & SKL_DRAM_RANK_MASK;
+
+   /*
+* If any of the slot has dual rank memory consider
+* dual rank memory channel
+*/
+   if (l_rank == SKL_DRAM_RANK_DUAL || s_rank == SKL_DRAM_RANK_DUAL)
+   ch_rank = DRAM_RANK_DUAL;
+
+   /*
+* If both the slot has single rank memory then configuration
+* is dual rank memory
+*/
+   if ((l_size && l_rank == SKL_DRAM_RANK_SINGLE) &&
+   (s_size && s_rank == SKL_DRAM_RANK_SINGLE))
+   ch_rank = DRAM_RANK_DUAL;
+   return ch_rank;
+}
+
+static int
+skl_get_memdev_info(struct drm_i915_private *dev_priv)
+{
+   struct memdev_info *memdev_info = _priv->memdev_info;
+   uint32_t mem_freq_khz;
+   uint32_t val;
+   enum rank ch0_rank, ch1_rank;
+
+   val = I915_READ(SKL_MC_BIOS_DATA_0_0_0_MCHBAR_PCU);
+   mem_freq_khz = (val & SKL_REQ_DATA_MASK) *
+   SKL_MEMORY_FREQ_MULTIPLIER_KHZ;
+
+   val = I915_READ(SKL_MAD_DIMM_CH0_0_0_0_MCHBAR_MCMAIN);
+   if (val != 0x0) {
+   memdev_info->num_channels++;
+   ch0_rank = skl_memdev_get_channel_rank(val);
+   }
+
+   val = I915_READ(SKL_MAD_DIMM_CH1_0_0_0_MCHBAR_MCMAIN);
+   if (val != 0x0) {
+   memdev_info->num_channels++;
+   ch1_rank = skl_memdev_get_channel_rank(val);
+   }
+
+   if (memdev_info->num_channels == 0) {
+   DRM_ERROR("Number of mem channels are zero\n");
+   return -EINVAL;
+   }
+
+   memdev_info->bandwidth_kbps = (memdev_info->num_channels *
+   mem_freq_khz * 8);
+
+   if (memdev_info->bandwidth_kbps == 0) {
+   DRM_ERROR("Couldn't get system memory bandwidth\n");
+   return -EINVAL;
+   }
+   memdev_info->valid = true;
+
+   /*
+* If any of channel is single rank channel,
+* consider single rank memory
+*/
+   if (ch0_rank == DRAM_RANK_SINGLE || ch1_rank == DRAM_RANK_SINGLE)
+   memdev_info->rank = DRAM_RANK_SINGLE;
+   else
+   memdev_info->rank = max(ch0_rank, ch1_rank);
+
+   return 0;
+}
+
+static int
+bxt_get_memdev_info(struct drm_i915_private *dev_priv)
+{
+   struct memdev_info *memdev_info = _priv->memdev_info;
+   uint32_t dram_channels;
+   uint32_t mem_freq_khz, val;
+   uint8_t num_active_channels;
+   int i;
+
+   val = I915_READ(BXT_P_CR_MC_BIOS_REQ_0_0_0);
+   mem_freq_khz = ((val & BXT_REQ_DATA_MASK) *
+   BXT_MEMORY_FREQ_MULTIPLIER_KHZ);
+
+   dram_channels = (val >> BXT_DRAM_CHANNEL_ACTIVE_SHIFT) &
+   BXT_DRAM_CHANNEL_ACTIVE_MASK;
+   num_active_channels = hweight32(dram_channels);
+
+   memdev_info->bandwidth_kbps = (mem_freq_khz * num_active_channels * 4);
+
+   if (memdev_info->bandwidth_kbps == 0) {
+   DRM_ERROR("Couldn't get system memory bandwidth\n");
+   return -EINVAL;
+   }
+   memdev_info->valid = true;
+
+   /*
+* Now read each DUNIT8/9/10/11 to check the rank of each dimms.
+*/
+   for (i = 0; i < BXT_D_CR_DRP0_DUNIT_MAX; i++) {
+   val = I915_READ(BXT_D_CR_DRP0_DUNIT(i));
+   if (val != 0x) {
+   uint8_t rank;
+   enum rank ch_rank;
+
+   memdev_info->num_channels++;
+   rank = val & BXT_DRAM_RANK_MASK;
+   if 

[Intel-gfx] [PATCH v5 0/8] GEN-9 Arbitrated Bandwidth WM WA's & IPC

[Mahesh Kumar]

This series implements following set of functionality
Implement IPC WA's for Broxton/KBL
Enable IPC in supported platforms
Convert WM calculation to fixed point calculation
Calculation of System memory Bandwidth for SKL/KBL/BXT
Implementation of Arbitrated memory Bandwidth related WM WA's


Mahesh Kumar (8):
  drm/i915/skl: Add variables to check x_tile and y_tile
  drm/i915/bxt: IPC WA for Broxton
  drm/i915/kbl: IPC workaround for kabylake
  drm/i915/bxt: Enable IPC support
  drm/i915/skl+: change WM calc to fixed point 16.16
  drm/i915: Add intel_atomic_get_existing_crtc_state function
  drm/i915: Decode system memory bandwidth
  drm/i915/gen9: WM memory bandwidth related workaround

 drivers/gpu/drm/i915/i915_drv.c  | 175 ++
 drivers/gpu/drm/i915/i915_drv.h  | 107 
 drivers/gpu/drm/i915/i915_reg.h  |  38 ++
 drivers/gpu/drm/i915/intel_drv.h |  15 +++
 drivers/gpu/drm/i915/intel_pm.c  | 265 ---
 5 files changed, 553 insertions(+), 47 deletions(-)

-- 
2.10.1

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

Re: [Intel-gfx] [PATCH v2] drm/i915: Pass dev_priv to intel_setup_outputs()

[kbuild test robot]

Hi Ander,

[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on next-20161123]
[cannot apply to v4.9-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Ander-Conselvan-de-Oliveira/drm-i915-Pass-dev_priv-to-intel_setup_outputs/20161124-093455
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

   make[3]: warning: jobserver unavailable: using -j1.  Add '+' to parent make 
rule.
   include/linux/init.h:1: warning: no structured comments found
   include/linux/workqueue.h:392: warning: No description found for parameter 
'...'
   include/linux/workqueue.h:392: warning: Excess function parameter 'args' 
description in 'alloc_workqueue'
   include/linux/workqueue.h:413: warning: No description found for parameter 
'...'
   include/linux/workqueue.h:413: warning: Excess function parameter 'args' 
description in 'alloc_ordered_workqueue'
   include/linux/kthread.h:26: warning: No description found for parameter '...'
   kernel/sys.c:1: warning: no structured comments found
   drivers/dma-buf/seqno-fence.c:1: warning: no structured comments found
   include/sound/core.h:324: warning: No description found for parameter '...'
   include/sound/core.h:335: warning: No description found for parameter '...'
   include/sound/core.h:388: warning: No description found for parameter '...'
   include/drm/drm_drv.h:295: warning: Incorrect use of kernel-doc format:  
 * Hook for allocating the GEM object struct, for use by core
   include/drm/drm_drv.h:407: warning: No description found for parameter 'load'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'firstopen'
   include/drm/drm_drv.h:407: warning: No description found for parameter 'open'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'preclose'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'postclose'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'lastclose'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'unload'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'dma_ioctl'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'dma_quiescent'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'context_dtor'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'set_busid'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'irq_handler'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'irq_preinstall'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'irq_postinstall'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'irq_uninstall'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'debugfs_init'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'debugfs_cleanup'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'gem_open_object'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'gem_close_object'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'gem_create_object'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'prime_handle_to_fd'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'prime_fd_to_handle'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'gem_prime_export'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'gem_prime_import'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'gem_prime_pin'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'gem_prime_unpin'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'gem_prime_res_obj'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'gem_prime_get_sg_table'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'gem_prime_import_sg_table'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'gem_prime_vmap'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'gem_prime_vunmap'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'gem_prime_mmap'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'vgaarb_irq'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'gem_vm_ops'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'major'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'minor'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'patc

Re: [Intel-gfx] [igvt-g-dev] [bug report] drm/i915/gvt: fix deadlock in workload_thread

[Zhenyu Wang]

On 2016.11.24 01:17:06 +0300, Dan Carpenter wrote:
> Hello Pei Zhang,
> 
> The patch 90d27a1b180e: "drm/i915/gvt: fix deadlock in
> workload_thread" from Nov 14, 2016, leads to the following static
> checker warning:
> 
>   drivers/gpu/drm/i915/gvt/scheduler.c:217 dispatch_workload()
>   warn: inconsistent returns 'mutex:_priv->drm.struct_mutex'.
> 
> drivers/gpu/drm/i915/gvt/scheduler.c
>161  static int dispatch_workload(struct intel_vgpu_workload *workload)
>162  {
>163  int ring_id = workload->ring_id;
>164  struct i915_gem_context *shadow_ctx = 
> workload->vgpu->shadow_ctx;
>165  struct drm_i915_private *dev_priv = 
> workload->vgpu->gvt->dev_priv;
>166  struct drm_i915_gem_request *rq;
>167  int ret;
>168  
>169  gvt_dbg_sched("ring id %d prepare to dispatch workload %p\n",
>170  ring_id, workload);
>171  
>172  shadow_ctx->desc_template = 
> workload->ctx_desc.addressing_mode <<
>173  GEN8_CTX_ADDRESSING_MODE_SHIFT;
>174  
>175  mutex_lock(_priv->drm.struct_mutex);
>176  
>177  rq = i915_gem_request_alloc(dev_priv->engine[ring_id], 
> shadow_ctx);
>178  if (IS_ERR(rq)) {
>179  gvt_err("fail to allocate gem request\n");
>180  workload->status = PTR_ERR(rq);
>181  return workload->status;
> 
> We're holding the lock here, which is obviously a bug.  But also should
> we goto out?  I always thought that functions with an "out" label were
> future proof?
>

Thanks, Dan. Yes, missed alloc failure path. How about below one? Pei, is it 
fine for you?

diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
b/drivers/gpu/drm/i915/gvt/scheduler.c
index f898df3..4db2422 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -177,8 +177,8 @@ static int dispatch_workload(struct intel_vgpu_workload 
*workload)
rq = i915_gem_request_alloc(dev_priv->engine[ring_id], shadow_ctx);
if (IS_ERR(rq)) {
gvt_err("fail to allocate gem request\n");
-   workload->status = PTR_ERR(rq);
-   return workload->status;
+   ret = PTR_ERR(rq);
+   goto out;
}
 
gvt_dbg_sched("ring id %d get i915 gem request %p\n", ring_id, rq);
@@ -212,7 +212,8 @@ static int dispatch_workload(struct intel_vgpu_workload 
*workload)
if (ret)
workload->status = ret;
 
-   i915_add_request_no_flush(rq);
+   if (!IS_ERR_OR_NULL(rq))
+   i915_add_request_no_flush(rq);
mutex_unlock(_priv->drm.struct_mutex);
return ret;
 }
@@ -460,7 +461,8 @@ static int workload_thread(void *priv)
 
complete_current_workload(gvt, ring_id);
 
-   i915_gem_request_put(fetch_and_zero(>req));
+   if (workload->req)
+   i915_gem_request_put(fetch_and_zero(>req));
 
if (need_force_wake)
intel_uncore_forcewake_put(gvt->dev_priv,


-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


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

[Intel-gfx] [PATCH RFC v2] drm: Add a new connector atomic property for link status

[Manasi Navare]

This is RFC patch for adding a connector link-status property
and making it atomic by adding it to the drm_connector_state.
This is to make sure its wired properly in drm_atomic_connector_set_property
and drm_atomic_connector_get_property functions.

v2:
* Removed connector->link_status (Daniel Vetter)
* Set connector->state->link_status in 
drm_mode_connector_set_link_status_property
(Daniel Vetter)
* Set the connector_changed flag to true if connector->state->link_status 
changed.
* Reset link_status to GOOD in update_output_state (Daniel Vetter)
* Never allow userspace to set link status from Good To Bad (Daniel Vetter)

Cc: Jani Nikula 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Cc: Sean Paul 
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/drm_atomic.c| 10 ++
 drivers/gpu/drm/drm_atomic_helper.c |  8 +
 drivers/gpu/drm/drm_connector.c | 61 -
 include/drm/drm_connector.h | 18 ++-
 include/drm/drm_mode_config.h   |  5 +++
 include/uapi/drm/drm_mode.h |  4 +++
 6 files changed, 104 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 89737e4..2cfaea9 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1087,6 +1087,14 @@ int drm_atomic_connector_set_property(struct 
drm_connector *connector,
 * now?) atomic writes to DPMS property:
 */
return -EINVAL;
+   } else if (property == config->link_status_property) {
+   /* Never downgrade from GOOD to BAD on userspace's request here,
+* only hw issues can do that.
+*/
+   if (state->link_status == GOOD)
+   return 0;
+   state->link_status = val;
+   return 0;
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(connector,
state, property, val);
@@ -1135,6 +1143,8 @@ static void drm_atomic_connector_print_state(struct 
drm_printer *p,
*val = (state->crtc) ? state->crtc->base.id : 0;
} else if (property == config->dpms_property) {
*val = connector->dpms;
+   } else if (property == config->link_status_property) {
+   *val = state->link_status;
} else if (connector->funcs->atomic_get_property) {
return connector->funcs->atomic_get_property(connector,
state, property, val);
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 494680c..962ed66 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -519,6 +519,13 @@ static int handle_conflicting_encoders(struct 
drm_atomic_state *state,
   connector_state);
if (ret)
return ret;
+   if (connector->state->crtc) {
+   crtc_state = drm_atomic_get_existing_crtc_state(state,
+   
connector->state->crtc);
+   if (connector->state->link_status !=
+   connector_state->link_status)
+   crtc_state->connectors_changed = true;
+   }
}
 
/*
@@ -2258,6 +2265,7 @@ static int update_output_state(struct drm_atomic_state 
*state,
NULL);
if (ret)
return ret;
+   conn_state->link_status = DRM_LINK_STATUS_GOOD;
}
}
 
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 5a45262..cd53c39 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -243,6 +243,10 @@ int drm_connector_init(struct drm_device *dev,
drm_object_attach_property(>base,
  config->dpms_property, 0);
 
+   drm_object_attach_property(>base,
+  config->link_status_property,
+  0);
+
if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
drm_object_attach_property(>base, 
config->prop_crtc_id, 0);
}
@@ -506,6 +510,12 @@ const char *drm_get_subpixel_order_name(enum 
subpixel_order order)
 };
 DRM_ENUM_NAME_FN(drm_get_dpms_name, drm_dpms_enum_list)
 
+static const struct drm_prop_enum_list drm_link_status_enum_list[] = {
+   { DRM_MODE_LINK_STATUS_GOOD, "Good" },
+   { DRM_MODE_LINK_STATUS_BAD, "Bad" },
+};
+DRM_ENUM_NAME_FN(drm_get_link_status_name, drm_link_status_enum_list)
+
 /**
  * 

Re: [Intel-gfx] [PATCH 8/8] drm/i915/get_params: Add HuC status to getparams

[Jeff McGee]

On Wed, Nov 23, 2016 at 02:27:43PM -0800, Anusha Srivatsa wrote:
> From: Peter Antoine 
> 
> This patch will allow for getparams to return the status of the HuC.
> As the HuC has to be validated by the GuC this patch uses the validated
> status to show when the HuC is loaded and ready for use. You cannot use
> the loaded status as with the GuC as the HuC is verified after it is
> loaded and is not usable until it is verified.
> 
> v2: removed the forewakes as the registers are already force-woken.
>  (T.Ursulin)
> v4: rebased.
> v5: rebased.
> v6: rebased.
> v7: rebased.
> v8: rebased.
> 
> Tested-by: Xiang Haihao 
> Signed-off-by: Anusha Srivatsa 
> Signed-off-by: Peter Antoine 
> Reviewed-by: Rodrigo Vivi 
> Reviewed-by: Jeff McGee 
> ---
>  drivers/gpu/drm/i915/i915_drv.c |  8 
>  drivers/gpu/drm/i915/intel_huc.h|  1 +
>  drivers/gpu/drm/i915/intel_huc_loader.c | 13 +
>  include/uapi/drm/i915_drm.h |  1 +
>  4 files changed, 23 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index b893e67..f2d5b0f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -49,6 +49,8 @@
>  #include "i915_trace.h"
>  #include "i915_vgpu.h"
>  #include "intel_drv.h"
> +#include "intel_guc.h"
> +#include "intel_huc.h"
>  
>  static struct drm_driver driver;
>  
> @@ -350,6 +352,9 @@ static int i915_getparam(struct drm_device *dev, void 
> *data,
>*/
>   value = 1;
>   break;
> + case I915_PARAM_HAS_HUC:
> + value = intel_is_huc_valid(dev_priv);
> + break;
>   default:
>   DRM_DEBUG("Unknown parameter %d\n", param->param);
>   return -EINVAL;
> @@ -603,6 +608,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
>   if (ret)
>   goto cleanup_irq;
>  
> + intel_huc_init(dev);
As we discussed, this needs to be in patch 3.

>   intel_guc_init(dev);
>  
>   ret = i915_gem_init(dev);
> @@ -630,6 +636,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
>   DRM_ERROR("failed to idle hardware; continuing to unload!\n");
>   i915_gem_fini(dev_priv);
>  cleanup_irq:
> + intel_huc_fini(dev);
>   intel_guc_fini(dev);
>   drm_irq_uninstall(dev);
>   intel_teardown_gmbus(dev);
> @@ -1325,6 +1332,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_priv);
>   intel_fbc_cleanup_cfb(dev_priv);
> diff --git a/drivers/gpu/drm/i915/intel_huc.h 
> b/drivers/gpu/drm/i915/intel_huc.h
> index 3ce0299..2e150be 100644
> --- a/drivers/gpu/drm/i915/intel_huc.h
> +++ b/drivers/gpu/drm/i915/intel_huc.h
> @@ -39,4 +39,5 @@ struct intel_huc {
>  void intel_huc_init(struct drm_device *dev);
>  void intel_huc_fini(struct drm_device *dev);
>  int intel_huc_load(struct drm_device *dev);
> +extern int intel_is_huc_valid(struct drm_i915_private *dev_priv);
>  #endif
> diff --git a/drivers/gpu/drm/i915/intel_huc_loader.c 
> b/drivers/gpu/drm/i915/intel_huc_loader.c
> index 3a2555e..8c3993b 100644
> --- a/drivers/gpu/drm/i915/intel_huc_loader.c
> +++ b/drivers/gpu/drm/i915/intel_huc_loader.c
> @@ -291,3 +291,16 @@ void intel_huc_fini(struct drm_device *dev)
>  
>   huc_fw->fetch_status = UC_FIRMWARE_NONE;
>  }
> +
> +/**
> + * intel_is_huc_valid() - Check to see if the HuC is fully loaded.
> + * @dev_priv:drm device to check.
> + *
> + * This function will return true if the guc has been loaded and
> + * has valid firmware. The simplest way of doing this is to check
> + * if the HuC has been validated, if so it must have been loaded.
> + */
> +int intel_is_huc_valid(struct drm_i915_private *dev_priv)
> +{
> + return ((I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED) != 0);
> +}
> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> index bdfc688..0a9dac4 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -390,6 +390,7 @@ typedef struct drm_i915_irq_wait {
>  #define I915_PARAM_HAS_POOLED_EU  38
>  #define I915_PARAM_MIN_EU_IN_POOL 39
>  #define I915_PARAM_MMAP_GTT_VERSION   40
> +#define I915_PARAM_HAS_HUC42
>  
>  /* Query whether DRM_I915_GEM_EXECBUFFER2 supports user defined execution
>   * priorities and the driver will attempt to execute batches in priority 
> order.
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org

[Intel-gfx] [PATCH] drm/i915: Always load guc by default.

[Anusha Srivatsa]

Remove the enable_guc_loading parameter. Load the GuC on
plaforms that have GuC. All issues we found so far are related
to GuC features like the command submission, but no bug is related
to the guc loading itself.

This addresses the case when we need GuC loaded even with no GuC feature
in use, like - GuC  authenticating HuC loading.

If we need to debug GuC we can do so by removing the firmware from
the rootfs instead of disabling with a parameter. So besides enabling
guc by default this patch also kill the use of the parameter for
loading.

Cc: Chris Wilson 
Signed-off-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/i915_params.c  |  6 --
 drivers/gpu/drm/i915/i915_params.h  |  1 -
 drivers/gpu/drm/i915/intel_guc_loader.c | 19 ++-
 3 files changed, 6 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index d46ffe7..a8011f2 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -56,7 +56,6 @@ struct i915_params i915 __read_mostly = {
.verbose_state_checks = 1,
.nuclear_pageflip = 0,
.edp_vswing = 0,
-   .enable_guc_loading = 0,
.enable_guc_submission = 0,
.guc_log_level = -1,
.enable_dp_mst = true,
@@ -216,11 +215,6 @@ MODULE_PARM_DESC(edp_vswing,
 "(0=use value from vbt [default], 1=low power swing(200mV),"
 "2=default swing(400mV))");
 
-module_param_named_unsafe(enable_guc_loading, i915.enable_guc_loading, int, 
0400);
-MODULE_PARM_DESC(enable_guc_loading,
-   "Enable GuC firmware loading "
-   "(-1=auto, 0=never [default], 1=if available, 2=required)");
-
 module_param_named_unsafe(enable_guc_submission, i915.enable_guc_submission, 
int, 0400);
 MODULE_PARM_DESC(enable_guc_submission,
"Enable GuC submission "
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 817ad95..4b7529a 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -45,7 +45,6 @@ struct i915_params {
int enable_ips;
int invert_brightness;
int enable_cmd_parser;
-   int enable_guc_loading;
int enable_guc_submission;
int guc_log_level;
int use_mmio_flip;
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 6946311..d48dc73 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -460,11 +460,9 @@ int intel_guc_setup(struct drm_device *dev)
fw_path,
intel_uc_fw_status_repr(guc_fw->fetch_status),
intel_uc_fw_status_repr(guc_fw->load_status));
-
-   /* Loading forbidden, or no firmware to load? */
-   if (!i915.enable_guc_loading) {
-   err = 0;
-   goto fail;
+   if (!HAS_GUC(dev_priv)) { 
+   /* Platform does not have a GuC */  
+   return;
} else if (fw_path == NULL) {
/* Device is known to have no uCode (e.g. no GuC) */
err = -ENXIO;
@@ -562,9 +560,8 @@ int intel_guc_setup(struct drm_device *dev)
 * nonfatal error (i.e. it doesn't prevent driver load, but
 * marks the GPU as wedged until reset).
 */
-   if (i915.enable_guc_loading > 1) {
-   ret = -EIO;
-   } else if (i915.enable_guc_submission > 1) {
+
+   if (i915.enable_guc_submission > 1) {
ret = -EIO;
} else {
ret = 0;
@@ -745,12 +742,9 @@ void intel_guc_init(struct drm_device *dev)
const char *fw_path;
 
if (!HAS_GUC(dev_priv)) {
-   i915.enable_guc_loading = 0;
i915.enable_guc_submission = 0;
} else {
/* A negative value means "use platform default" */
-   if (i915.enable_guc_loading < 0)
-   i915.enable_guc_loading = HAS_GUC_UCODE(dev_priv);
if (i915.enable_guc_submission < 0)
i915.enable_guc_submission = HAS_GUC_SCHED(dev_priv);
}
@@ -778,8 +772,7 @@ void intel_guc_init(struct drm_device *dev)
guc_fw->fetch_status = UC_FIRMWARE_NONE;
guc_fw->load_status = UC_FIRMWARE_NONE;
 
-   /* Early (and silent) return if GuC loading is disabled */
-   if (!i915.enable_guc_loading)
+   if(!HAS_GUC(dev_priv))
return;
if (fw_path == NULL)
return;
-- 
2.7.4

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

[Intel-gfx] [PATCH] aubdump: Fix intel_aubdump -o

[Kenneth Graunke]

This looks like a mistake in 1f43677f895a88ae880b35f9b18cc7e6869d0ca6.
---
 tools/intel_aubdump.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

This code still looks really weird.  ${foo:bar} means "the value of $foo,
unless it's unset/empty, in which case 'bar'.  But if $file is empty...
then we process $file?  Maybe I'm not reading it right.

diff --git a/tools/intel_aubdump.in b/tools/intel_aubdump.in
index 343dc29..977fe95 100644
--- a/tools/intel_aubdump.in
+++ b/tools/intel_aubdump.in
@@ -36,31 +36,31 @@ function add_arg() {
 function build_command () {
   command=""
   for i in $1; do
  if [ -z $command ]; then
  command=$i
  else
  command="$command,$i"
  fi;
   done
 }
 
 while true; do
   case "$1" in
  -o)
  file=$2
- add_arg "file=${f:-$(basename ${f}).aub}"
+ add_arg "file=${file:-$(basename ${file}).aub}"
  shift 2
  ;;
  -v)
  add_arg "verbose=1"
  shift 1
  ;;
  -o*)
  file=${1##-o}
  add_arg "file=${file:-$(basename ${file}).aub}"
  shift
  ;;
  --output=*)
  file=${1##--output=}
  add_arg "file=${file:-$(basename ${file}).aub}"
  shift
-- 
2.10.2

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: kick out cmd_parser specific structs from i915_drv.h

[Patchwork]

== Series Details ==

Series: drm/i915: kick out cmd_parser specific structs from i915_drv.h
URL   : https://patchwork.freedesktop.org/series/15854/
State : success

== Summary ==

Series 15854v1 drm/i915: kick out cmd_parser specific structs from i915_drv.h
https://patchwork.freedesktop.org/api/1.0/series/15854/revisions/1/mbox/


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

a08f9fc55a649334a2788a804904d920f8b2fda2 drm-intel-nightly: 
2016y-11m-23d-20h-25m-10s UTC integration manifest
1e81a81 drm/i915: kick out cmd_parser specific structs from i915_drv.h

== Logs ==

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

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Add support for DP link training compliance

[Manasi Navare]

On Wed, Nov 23, 2016 at 03:07:30PM +0200, Jani Nikula wrote:
> On Tue, 22 Nov 2016, Manasi Navare  wrote:
> > This patch adds support to handle automated DP compliance
> > link training test requests. This patch has been tested with
> > Unigraf DPR-120 DP Compliance device for testing Link
> > Training Compliance.
> > After we get a short pulse Compliance test request, test
> > request values are read and hotplug uevent is sent in order
> > to trigger another modeset during which the pipe is configured
> > and link is retrained and enabled for link parameters requested
> > by the test.
> >
> > Signed-off-by: Manasi Navare 
> > Cc: Jani Nikula 
> > Cc: Daniel Vetter 
> > Cc: Ville Syrjala 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c  | 73 
> > 
> >  drivers/gpu/drm/i915/intel_drv.h |  2 ++
> >  2 files changed, 69 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 90283ed..69944d1 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -288,6 +288,21 @@ static int intel_dp_common_rates(struct intel_dp 
> > *intel_dp,
> >common_rates);
> >  }
> >  
> > +static int intel_dp_link_rate_index(struct intel_dp *intel_dp,
> > +   int *common_rates, int link_rate)
> > +{
> > +   int common_len;
> > +   int index;
> > +
> > +   common_len = intel_dp_common_rates(intel_dp, common_rates);
> > +   for (index = 0; index < common_len; index++) {
> > +   if (link_rate == common_rates[common_len - index - 1])
> > +   return common_len - index - 1;
> > +   }
> > +
> > +   return -1;
> > +}
> > +
> >  static enum drm_mode_status
> >  intel_dp_mode_valid(struct drm_connector *connector,
> > struct drm_display_mode *mode)
> > @@ -1554,6 +1569,7 @@ static int intel_dp_compute_bpp(struct intel_dp 
> > *intel_dp,
> > /* Conveniently, the link BW constants become indices with a shift...*/
> > int min_clock = 0;
> > int max_clock;
> > +   int link_rate_index;
> > int bpp, mode_rate;
> > int link_avail, link_clock;
> > int common_rates[DP_MAX_SUPPORTED_RATES] = {};
> > @@ -1595,6 +1611,16 @@ static int intel_dp_compute_bpp(struct intel_dp 
> > *intel_dp,
> > if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK)
> > return false;
> >  
> > +   /* Use values requested by Compliance Test Request */
> > +   if (intel_dp->compliance_test_type == DP_TEST_LINK_TRAINING) {
> > +   link_rate_index = intel_dp_link_rate_index(intel_dp,
> > +  common_rates,
> > +  
> > drm_dp_bw_code_to_link_rate(intel_dp->compliance_test_link_rate));
> > +   if (link_rate_index >= 0)
> > +   min_clock = max_clock = link_rate_index;
> > +   min_lane_count = max_lane_count = 
> > intel_dp->compliance_test_lane_count;
> 
> You need to be more strict about validating
> compliance_test_lane_count. You do mask it with DP_MAX_LANE_COUNT_MASK,
> but that's 0x1f, quite a few more lanes than we have...
>

So the reason I didnt add validation here is because we enter the DUT 
capabilities into
DPR-120 before starting the test, so the test lane count its gonna request will 
not
exceed the DUT max lane count.
But we can still take safe approach and take the min between the 
compliance_lane_count and
max source lane count.

 
> > +   }
> > +
> > DRM_DEBUG_KMS("DP link computation with max lane count %i "
> >   "max bw %d pixel clock %iKHz\n",
> >   max_lane_count, common_rates[max_clock],
> > @@ -1642,6 +1668,7 @@ static int intel_dp_compute_bpp(struct intel_dp 
> > *intel_dp,
> > }
> > }
> > }
> > +
> 
> Please pay attention to not making unrelated changes.
> 
> > }
> >  
> > return false;
> > @@ -3804,6 +3831,29 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, u8 
> > *crc)
> >  static uint8_t intel_dp_autotest_link_training(struct intel_dp *intel_dp)
> >  {
> > uint8_t test_result = DP_TEST_ACK;
> > +   int status = 0;
> > +   /* (DP CTS 1.2)
> > +* 4.3.1.11
> > +*/
> > +   /* Read the TEST_LANE_COUNT and TEST_LINK_RTAE fields (DP CTS 3.1.4) */
> > +   status = drm_dp_dpcd_readb(_dp->aux, DP_TEST_LANE_COUNT,
> > + _dp->compliance_test_lane_count);
> > +
> > +   if (status <= 0) {
> > +   DRM_DEBUG_KMS("Could not read test lane count from "
> > + "reference sink\n");
> 
> No need to be so verbose, DRM_DEBUG_KMS will include the function name,
> so a simple "Lane count read failed" 

[Intel-gfx] [PATCH] drm/i915: kick out cmd_parser specific structs from i915_drv.h

[Matthew Auld]

No sense in keeping the cmd_descriptor and cmd_table structs in
i915_drv.h, now that they are no longer referenced externally.

Cc: Chris Wilson 
Signed-off-by: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_cmd_parser.c | 96 ++
 drivers/gpu/drm/i915/i915_drv.h| 96 --
 2 files changed, 96 insertions(+), 96 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index f5762cde288b..0b25f66653a7 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -86,6 +86,102 @@
  * general bitmasking mechanism.
  */
 
+/*
+ * A command that requires special handling by the command parser.
+ */
+struct drm_i915_cmd_descriptor {
+   /*
+* Flags describing how the command parser processes the command.
+*
+* CMD_DESC_FIXED: The command has a fixed length if this is set,
+* a length mask if not set
+* CMD_DESC_SKIP: The command is allowed but does not follow the
+*standard length encoding for the opcode range in
+*which it falls
+* CMD_DESC_REJECT: The command is never allowed
+* CMD_DESC_REGISTER: The command should be checked against the
+*register whitelist for the appropriate ring
+* CMD_DESC_MASTER: The command is allowed if the submitting process
+*  is the DRM master
+*/
+   u32 flags;
+#define CMD_DESC_FIXED(1<<0)
+#define CMD_DESC_SKIP (1<<1)
+#define CMD_DESC_REJECT   (1<<2)
+#define CMD_DESC_REGISTER (1<<3)
+#define CMD_DESC_BITMASK  (1<<4)
+#define CMD_DESC_MASTER   (1<<5)
+
+   /*
+* The command's unique identification bits and the bitmask to get them.
+* This isn't strictly the opcode field as defined in the spec and may
+* also include type, subtype, and/or subop fields.
+*/
+   struct {
+   u32 value;
+   u32 mask;
+   } cmd;
+
+   /*
+* The command's length. The command is either fixed length (i.e. does
+* not include a length field) or has a length field mask. The flag
+* CMD_DESC_FIXED indicates a fixed length. Otherwise, the command has
+* a length mask. All command entries in a command table must include
+* length information.
+*/
+   union {
+   u32 fixed;
+   u32 mask;
+   } length;
+
+   /*
+* Describes where to find a register address in the command to check
+* against the ring's register whitelist. Only valid if flags has the
+* CMD_DESC_REGISTER bit set.
+*
+* A non-zero step value implies that the command may access multiple
+* registers in sequence (e.g. LRI), in that case step gives the
+* distance in dwords between individual offset fields.
+*/
+   struct {
+   u32 offset;
+   u32 mask;
+   u32 step;
+   } reg;
+
+#define MAX_CMD_DESC_BITMASKS 3
+   /*
+* Describes command checks where a particular dword is masked and
+* compared against an expected value. If the command does not match
+* the expected value, the parser rejects it. Only valid if flags has
+* the CMD_DESC_BITMASK bit set. Only entries where mask is non-zero
+* are valid.
+*
+* If the check specifies a non-zero condition_mask then the parser
+* only performs the check when the bits specified by condition_mask
+* are non-zero.
+*/
+   struct {
+   u32 offset;
+   u32 mask;
+   u32 expected;
+   u32 condition_offset;
+   u32 condition_mask;
+   } bits[MAX_CMD_DESC_BITMASKS];
+};
+
+/*
+ * A table of commands requiring special handling by the command parser.
+ *
+ * Each engine has an array of tables. Each table consists of an array of
+ * command descriptors, which must be sorted with command opcodes in
+ * ascending order.
+ */
+struct drm_i915_cmd_table {
+   const struct drm_i915_cmd_descriptor *table;
+   int count;
+};
+
 #define STD_MI_OPCODE_SHIFT  (32 - 9)
 #define STD_3D_OPCODE_SHIFT  (32 - 16)
 #define STD_2D_OPCODE_SHIFT  (32 - 10)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e3f1a4b1b269..01f506728205 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2454,102 +2454,6 @@ static inline struct scatterlist *__sg_next(struct 
scatterlist *sg)
 (((__iter).curr += PAGE_SIZE) < (__iter).max) ||   \
 ((__iter) = __sgt_iter(__sg_next((__iter).sgp), false), 0))
 
-/*
- * A command that requires special handling by the command parser.
- */
-struct drm_i915_cmd_descriptor {
-   /*
-* 

[Intel-gfx] ✓ Fi.CI.BAT: success for HuC Loading Patches

[Patchwork]

== Series Details ==

Series: HuC Loading Patches
URL   : https://patchwork.freedesktop.org/series/15850/
State : success

== Summary ==

Series 15850v1 HuC Loading Patches
https://patchwork.freedesktop.org/api/1.0/series/15850/revisions/1/mbox/


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

a08f9fc55a649334a2788a804904d920f8b2fda2 drm-intel-nightly: 
2016y-11m-23d-20h-25m-10s UTC integration manifest
6d7057a drm/i915/get_params: Add HuC status to getparams
ead9afa drm/i915/huc: Support HuC authentication
fb821c1 drm/i915/huc: Add debugfs for HuC loading status check
4ee1095 drm/i915/HuC: Add KBL huC loading Support
0a3eca4 drm/i915/huc: Add BXT HuC Loading Support
e72e459 drm/i915/huc: Add HuC fw loading support
6d1eaa2 drm/i915/huc: Unified css_header struct for GuC and HuC
784ebbc drm/i915/guc: Make the GuC fw loading helper functions general. Always 
initialize action_lock

== Logs ==

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

[Intel-gfx] [PATCH 7/8] drm/i915/huc: Support HuC authentication

[Anusha Srivatsa]

From: Peter Antoine 

The HuC authentication is done by host2guc call. The HuC RSA keys
are sent to GuC for authentication.

v2: rebased on top of drm-intel-nightly.
changed name format and upped version 1.7.
v3: rebased on top of drm-intel-nightly.
v4: changed wait_for_automic to wait_for
v5: rebased.
v7: rebased.
v8: rebased.
v9: rebased. Rename intel_huc_auh() to intel_guc_auth_huc()
and place the prototype in intel_guc.h,correct the comments.
v10: rebased.
v11: rebased.

Tested-by: Xiang Haihao 
Signed-off-by: Anusha Srivatsa 
Signed-off-by: Alex Dai 
Signed-off-by: Peter Antoine 
Reviewed-by: Dave Gordon 
Reviewed-by: Jeff McGee 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 63 ++
 drivers/gpu/drm/i915/intel_guc.h   |  2 +-
 drivers/gpu/drm/i915/intel_guc_fwif.h  |  1 +
 drivers/gpu/drm/i915/intel_guc_loader.c|  2 +
 4 files changed, 67 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 9947a6d..704c2a0 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -27,6 +27,7 @@
 #include 
 #include "i915_drv.h"
 #include "intel_guc.h"
+#include "intel_huc.h"
 
 /**
  * DOC: GuC-based command submission
@@ -1728,3 +1729,65 @@ int i915_guc_log_control(struct drm_i915_private 
*dev_priv, u64 control_val)
 
return ret;
 }
+
+/**
+ * intel_guc_auth_huc() - authenticate ucode
+ * @dev: the drm device
+ *
+ * Triggers a HuC fw authentication request to the GuC via host-2-guc
+ * interface.
+ */
+void intel_guc_auth_huc(struct drm_device *dev)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct intel_guc *guc = _priv->guc;
+   struct intel_huc *huc = _priv->huc;
+   struct i915_vma *vma;
+   int ret;
+   u32 data[2];
+
+   /* Bypass the case where there is no HuC firmware */
+   if (huc->huc_fw.fetch_status == UC_FIRMWARE_NONE ||
+   huc->huc_fw.load_status == UC_FIRMWARE_NONE)
+   return;
+
+   if (guc->guc_fw.load_status != UC_FIRMWARE_SUCCESS) {
+   DRM_ERROR("HuC: GuC fw wasn't loaded. Can't authenticate");
+   return;
+   }
+
+   if (huc->huc_fw.load_status != UC_FIRMWARE_SUCCESS) {
+   DRM_ERROR("HuC: fw wasn't loaded. Nothing to authenticate");
+   return;
+   }
+
+   vma = i915_gem_object_ggtt_pin(huc->huc_fw.uc_fw_obj, NULL, 0, 0, 0);
+   if (IS_ERR(vma)) {
+   DRM_DEBUG_DRIVER("pin failed %d\n", (int)PTR_ERR(vma));
+   return;
+   }
+
+
+   /* Invalidate GuC TLB to let GuC take the latest updates to GTT. */
+   I915_WRITE(GEN8_GTCR, GEN8_GTCR_INVALIDATE);
+
+   /* Specify auth action and where public signature is. */
+   data[0] = HOST2GUC_ACTION_AUTHENTICATE_HUC;
+   data[1] = i915_ggtt_offset(vma) + huc->huc_fw.rsa_offset;
+
+   ret = host2guc_action(guc, data, ARRAY_SIZE(data));
+   if (ret) {
+   DRM_ERROR("HuC: GuC did not ack Auth request\n");
+   goto out;
+   }
+
+   /* Check authentication status, it should be done by now */
+   ret = wait_for((I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED) > 0, 50);
+   if (ret) {
+   DRM_ERROR("HuC: Authentication failed\n");
+   goto out;
+   }
+
+out:
+   i915_vma_unpin(vma);
+}
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index ff6aba6..67a500c 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -197,5 +197,5 @@ void i915_guc_flush_logs(struct drm_i915_private *dev_priv);
 void i915_guc_register(struct drm_i915_private *dev_priv);
 void i915_guc_unregister(struct drm_i915_private *dev_priv);
 int i915_guc_log_control(struct drm_i915_private *dev_priv, u64 control_val);
-
+void intel_guc_auth_huc(struct drm_device *dev);
 #endif
diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/intel_guc_fwif.h
index c2a7fdd..99a092d 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
@@ -513,6 +513,7 @@ enum host2guc_action {
HOST2GUC_ACTION_EXIT_S_STATE = 0x502,
HOST2GUC_ACTION_SLPC_REQUEST = 0x3003,
HOST2GUC_ACTION_UK_LOG_ENABLE_LOGGING = 0x0E000,
+   HOST2GUC_ACTION_AUTHENTICATE_HUC = 0x4000,
HOST2GUC_ACTION_LIMIT
 };
 
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 090c727..6946311 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -531,6 +531,8 @@ int intel_guc_setup(struct drm_device *dev)
intel_uc_fw_status_repr(guc_fw->fetch_status),

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

[Anusha Srivatsa]

From: Peter Antoine 

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).
v4: rebased + spaces.
v7: rebased.
v8: rebased.
v9: rebased. Rename device_id to guc_branch_client_version,
make guc_sw_version a union. . Put UC_FW_TYPE_GUC
and UC_FW_TYPE_HUC into an enum.
v10: rebased.
v11: rebased.

Tested-by: Xiang Haihao 
Signed-off-by: Anusha Srivatsa 
Signed-off-by: Alex Dai 
Signed-off-by: Peter Antoine 
Reviewed-by: Dave Gordon 
Reviewed-by: Jeff McGee 
---
 drivers/gpu/drm/i915/intel_guc.h|  6 +
 drivers/gpu/drm/i915/intel_guc_fwif.h   | 21 +
 drivers/gpu/drm/i915/intel_guc_loader.c | 41 ++---
 3 files changed, 51 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 6dc328f..45dfa40 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -98,6 +98,11 @@ enum intel_uc_fw_status {
UC_FIRMWARE_SUCCESS
 };
 
+enum {
+   UC_FW_TYPE_GUC,
+   UC_FW_TYPE_HUC
+};
+
 /*
  * This structure encapsulates all the data needed during the process
  * of fetching, caching, and loading the firmware image into the GuC.
@@ -115,6 +120,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 324ea90..c2a7fdd 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  |
  * +---+
@@ -181,9 +181,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. */
@@ -214,8 +221,14 @@ struct guc_css_header {
 
char username[8];
char buildnumber[12];
-   uint32_t device_id;
-   uint32_t guc_sw_version;
+   union {
+   uint32_t guc_branch_client_version;
+   uint32_t huc_sw_version;
+   };
+   union {
+   uint32_t guc_sw_version;
+   uint32_t huc_reserved;
+   };
uint32_t prod_preprod_fw;
uint32_t reserved[12];
uint32_t header_info;
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index c1b53a6..70b372b 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -593,7 +593,7 @@ void intel_uc_fw_fetch(struct drm_device *dev, struct 
intel_uc_fw *uc_fw)
struct pci_dev *pdev = dev->pdev;
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;
 
@@ -610,19 +610,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_NOTE("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 

[Intel-gfx] [PATCH 6/8] drm/i915/huc: Add debugfs for HuC loading status check

[Anusha Srivatsa]

From: Peter Antoine 

Add debugfs entry for HuC loading status check.

v2: rebase on-top of drm-intel-nightly.
v3: rebased again.
v7: rebased.
v8: rebased.
v9: rebased.
v10: rebased.

Tested-by: Xiang Haihao 
Signed-off-by: Anusha Srivatsa 
Signed-off-by: Alex Dai 
Signed-off-by: Peter Antoine 
Reviewed-by: Dave Gordon 
Reviewed-by: Jeff McGee 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 53305a4..97324e1 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2355,6 +2355,36 @@ static int i915_llc(struct seq_file *m, void *data)
return 0;
 }
 
+static int i915_huc_load_status_info(struct seq_file *m, void *data)
+{
+   struct drm_i915_private *dev_priv = node_to_i915(m->private);
+   struct intel_uc_fw *huc_fw = _priv->huc.huc_fw;
+
+   if (!HAS_HUC_UCODE(dev_priv))
+   return 0;
+
+   seq_puts(m, "HuC firmware status:\n");
+   seq_printf(m, "\tpath: %s\n", huc_fw->uc_fw_path);
+   seq_printf(m, "\tfetch: %s\n",
+   intel_uc_fw_status_repr(huc_fw->fetch_status));
+   seq_printf(m, "\tload: %s\n",
+   intel_uc_fw_status_repr(huc_fw->load_status));
+   seq_printf(m, "\tversion wanted: %d.%d\n",
+   huc_fw->major_ver_wanted, huc_fw->minor_ver_wanted);
+   seq_printf(m, "\tversion found: %d.%d\n",
+   huc_fw->major_ver_found, huc_fw->minor_ver_found);
+   seq_printf(m, "\theader: offset is %d; size = %d\n",
+   huc_fw->header_offset, huc_fw->header_size);
+   seq_printf(m, "\tuCode: offset is %d; size = %d\n",
+   huc_fw->ucode_offset, huc_fw->ucode_size);
+   seq_printf(m, "\tRSA: offset is %d; size = %d\n",
+   huc_fw->rsa_offset, huc_fw->rsa_size);
+
+   seq_printf(m, "\nHuC status 0x%08x:\n", I915_READ(HUC_STATUS2));
+
+   return 0;
+}
+
 static int i915_guc_load_status_info(struct seq_file *m, void *data)
 {
struct drm_i915_private *dev_priv = node_to_i915(m->private);
@@ -5416,6 +5446,7 @@ static const struct drm_info_list i915_debugfs_list[] = {
{"i915_guc_info", i915_guc_info, 0},
{"i915_guc_load_status", i915_guc_load_status_info, 0},
{"i915_guc_log_dump", i915_guc_log_dump, 0},
+   {"i915_huc_load_status", i915_huc_load_status_info, 0},
{"i915_frequency_info", i915_frequency_info, 0},
{"i915_hangcheck_info", i915_hangcheck_info, 0},
{"i915_drpc_info", i915_drpc_info, 0},
-- 
2.7.4

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

[Intel-gfx] [PATCH 4/8] drm/i915/huc: Add BXT HuC Loading Support

[Anusha Srivatsa]

This patch adds the HuC Loading for the BXT by using
the updated file construction.

Version 1.7 of the HuC firmware.

v2: rebased.

Cc: Jeff Mcgee 
Signed-off-by: Anusha Srivatsa 
Reviewed-by: Jeff McGee 
---
 drivers/gpu/drm/i915/intel_huc_loader.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_huc_loader.c 
b/drivers/gpu/drm/i915/intel_huc_loader.c
index 1c9c096..f67bee7 100644
--- a/drivers/gpu/drm/i915/intel_huc_loader.c
+++ b/drivers/gpu/drm/i915/intel_huc_loader.c
@@ -44,6 +44,10 @@
 #define SKL_FW_MINOR 07
 #define SKL_BLD_NUM 1398
 
+#define BXT_FW_MAJOR 01
+#define BXT_FW_MINOR 07
+#define BXT_BLD_NUM 1398
+
 #define HUC_FW_PATH(platform, major, minor, bld_num) \
"i915/" __stringify(platform) "_huc_ver" __stringify(major) "_" \
__stringify(minor) "_" __stringify(bld_num) ".bin"
@@ -52,6 +56,9 @@
SKL_FW_MINOR, SKL_BLD_NUM)
 MODULE_FIRMWARE(I915_SKL_HUC_UCODE);
 
+#define I915_BXT_HUC_UCODE HUC_FW_PATH(bxt, BXT_FW_MAJOR, \
+   BXT_FW_MINOR, BXT_BLD_NUM)
+MODULE_FIRMWARE(I915_BXT_HUC_UCODE);
 /**
  * huc_ucode_xfer() - DMA's the firmware
  * @dev_priv: the drm device
@@ -159,6 +166,10 @@ void intel_huc_init(struct drm_device *dev)
fw_path = I915_SKL_HUC_UCODE;
huc_fw->major_ver_wanted = SKL_FW_MAJOR;
huc_fw->minor_ver_wanted = SKL_FW_MINOR;
+   } else if (IS_BROXTON(dev_priv)) {
+   fw_path = I915_BXT_HUC_UCODE;
+   huc_fw->major_ver_wanted = BXT_FW_MAJOR;
+   huc_fw->minor_ver_wanted = BXT_FW_MINOR;
}
 
huc_fw->uc_fw_path = fw_path;
-- 
2.7.4

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

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

[Anusha Srivatsa]

From: Peter Antoine 

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_private to to_i915()
v4: moved function back to where it was.
change wait_for_atomic to wait_for.
v5: rebased + comment changes.
v7: rebased.
v8: rebased.
v9: rebased. Changed the year in the copyright message to reflect
the right year.Correct the comments,remove the unwanted WARN message,
replace drm_gem_object_unreference() with i915_gem_object_put().Make the
prototypes in intel_huc.h non-extern.
v10: rebased. Update the file construction done by HuC. It is similar to
GuC.Adopted the approach used in-
https://patchwork.freedesktop.org/patch/104355/ 
v11: Fix warnings remove old declaration
v12: Change dev to dev_priv in macro definition.
Corrected comments.
v13: rebased.

Cc: Tvrtko Ursulin 
Tested-by: Xiang Haihao 
Signed-off-by: Anusha Srivatsa 
Signed-off-by: Alex Dai 
Signed-off-by: Peter Antoine 
Reviewed-by: Dave Gordon 
---
 drivers/gpu/drm/i915/Makefile   |   1 +
 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|  42 +
 drivers/gpu/drm/i915/intel_huc_loader.c | 266 
 7 files changed, 320 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 580602d..c60e681 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -56,6 +56,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.h b/drivers/gpu/drm/i915/i915_drv.h
index c44f241..4d4e0a2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -56,6 +56,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"
 
@@ -1915,6 +1916,7 @@ struct drm_i915_private {
 
struct intel_gvt *gvt;
 
+   struct intel_huc huc;
struct intel_guc guc;
 
struct intel_csr csr;
@@ -2768,6 +2770,7 @@ intel_info(const struct drm_i915_private *dev_priv)
 #define HAS_GUC(dev_priv)  ((dev_priv)->info.has_guc)
 #define HAS_GUC_UCODE(dev_priv)(HAS_GUC(dev_priv))
 #define HAS_GUC_SCHED(dev_priv)(HAS_GUC(dev_priv))
+#define HAS_HUC_UCODE(dev_priv)(HAS_GUC(dev_priv))
 
 #define HAS_RESOURCE_STREAMER(dev_priv) 
((dev_priv)->info.has_resource_streamer)
 
diff --git a/drivers/gpu/drm/i915/i915_guc_reg.h 
b/drivers/gpu/drm/i915/i915_guc_reg.h
index a47e1e4..64e942a 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 45dfa40..ff6aba6 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -183,6 +183,7 @@ extern const char *intel_uc_fw_status_repr(enum 
intel_uc_fw_status status);
 extern int intel_guc_suspend(struct drm_device *dev);
 extern int intel_guc_resume(struct drm_device *dev);
 void intel_uc_fw_fetch(struct drm_device *dev, struct intel_uc_fw *uc_fw);
+u32 guc_wopcm_size(struct drm_i915_private *dev_priv);
 
 /* i915_guc_submission.c */
 int i915_guc_submission_init(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 70b372b..090c727 100644
--- 

[Intel-gfx] [PATCH 5/8] drm/i915/HuC: Add KBL huC loading Support

[Anusha Srivatsa]

This patch adds the support to load HuC on KBL
Version 2.0

v2: rebased.

Cc: Jeff Mcgee 
Signed-off-by: Anusha Srivatsa 
Reviewed-by: Jeff McGee 
---
 drivers/gpu/drm/i915/intel_huc_loader.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_huc_loader.c 
b/drivers/gpu/drm/i915/intel_huc_loader.c
index f67bee7..3a2555e 100644
--- a/drivers/gpu/drm/i915/intel_huc_loader.c
+++ b/drivers/gpu/drm/i915/intel_huc_loader.c
@@ -48,6 +48,10 @@
 #define BXT_FW_MINOR 07
 #define BXT_BLD_NUM 1398
 
+#define KBL_FW_MAJOR 02
+#define KBL_FW_MINOR 00
+#define KBL_BLD_NUM 1810
+
 #define HUC_FW_PATH(platform, major, minor, bld_num) \
"i915/" __stringify(platform) "_huc_ver" __stringify(major) "_" \
__stringify(minor) "_" __stringify(bld_num) ".bin"
@@ -59,6 +63,11 @@ MODULE_FIRMWARE(I915_SKL_HUC_UCODE);
 #define I915_BXT_HUC_UCODE HUC_FW_PATH(bxt, BXT_FW_MAJOR, \
BXT_FW_MINOR, BXT_BLD_NUM)
 MODULE_FIRMWARE(I915_BXT_HUC_UCODE);
+
+#define I915_KBL_HUC_UCODE HUC_FW_PATH(kbl, KBL_FW_MAJOR, \
+   KBL_FW_MINOR, KBL_BLD_NUM)
+MODULE_FIRMWARE(I915_KBL_HUC_UCODE);
+
 /**
  * huc_ucode_xfer() - DMA's the firmware
  * @dev_priv: the drm device
@@ -170,8 +179,15 @@ void intel_huc_init(struct drm_device *dev)
fw_path = I915_BXT_HUC_UCODE;
huc_fw->major_ver_wanted = BXT_FW_MAJOR;
huc_fw->minor_ver_wanted = BXT_FW_MINOR;
+   } else if (IS_KABYLAKE(dev_priv)) {
+   fw_path = I915_KBL_HUC_UCODE;
+   huc_fw->major_ver_wanted = KBL_FW_MAJOR;
+   huc_fw->minor_ver_wanted = KBL_FW_MINOR;
}
 
+   if (fw_path == NULL)
+   return;
+
huc_fw->uc_fw_path = fw_path;
huc_fw->fetch_status = UC_FIRMWARE_PENDING;
 
-- 
2.7.4

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

[Intel-gfx] [PATCH 8/8] drm/i915/get_params: Add HuC status to getparams

[Anusha Srivatsa]

From: Peter Antoine 

This patch will allow for getparams to return the status of the HuC.
As the HuC has to be validated by the GuC this patch uses the validated
status to show when the HuC is loaded and ready for use. You cannot use
the loaded status as with the GuC as the HuC is verified after it is
loaded and is not usable until it is verified.

v2: removed the forewakes as the registers are already force-woken.
 (T.Ursulin)
v4: rebased.
v5: rebased.
v6: rebased.
v7: rebased.
v8: rebased.

Tested-by: Xiang Haihao 
Signed-off-by: Anusha Srivatsa 
Signed-off-by: Peter Antoine 
Reviewed-by: Rodrigo Vivi 
Reviewed-by: Jeff McGee 
---
 drivers/gpu/drm/i915/i915_drv.c |  8 
 drivers/gpu/drm/i915/intel_huc.h|  1 +
 drivers/gpu/drm/i915/intel_huc_loader.c | 13 +
 include/uapi/drm/i915_drm.h |  1 +
 4 files changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index b893e67..f2d5b0f 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -49,6 +49,8 @@
 #include "i915_trace.h"
 #include "i915_vgpu.h"
 #include "intel_drv.h"
+#include "intel_guc.h"
+#include "intel_huc.h"
 
 static struct drm_driver driver;
 
@@ -350,6 +352,9 @@ static int i915_getparam(struct drm_device *dev, void *data,
 */
value = 1;
break;
+   case I915_PARAM_HAS_HUC:
+   value = intel_is_huc_valid(dev_priv);
+   break;
default:
DRM_DEBUG("Unknown parameter %d\n", param->param);
return -EINVAL;
@@ -603,6 +608,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
if (ret)
goto cleanup_irq;
 
+   intel_huc_init(dev);
intel_guc_init(dev);
 
ret = i915_gem_init(dev);
@@ -630,6 +636,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
DRM_ERROR("failed to idle hardware; continuing to unload!\n");
i915_gem_fini(dev_priv);
 cleanup_irq:
+   intel_huc_fini(dev);
intel_guc_fini(dev);
drm_irq_uninstall(dev);
intel_teardown_gmbus(dev);
@@ -1325,6 +1332,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_priv);
intel_fbc_cleanup_cfb(dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_huc.h b/drivers/gpu/drm/i915/intel_huc.h
index 3ce0299..2e150be 100644
--- a/drivers/gpu/drm/i915/intel_huc.h
+++ b/drivers/gpu/drm/i915/intel_huc.h
@@ -39,4 +39,5 @@ struct intel_huc {
 void intel_huc_init(struct drm_device *dev);
 void intel_huc_fini(struct drm_device *dev);
 int intel_huc_load(struct drm_device *dev);
+extern int intel_is_huc_valid(struct drm_i915_private *dev_priv);
 #endif
diff --git a/drivers/gpu/drm/i915/intel_huc_loader.c 
b/drivers/gpu/drm/i915/intel_huc_loader.c
index 3a2555e..8c3993b 100644
--- a/drivers/gpu/drm/i915/intel_huc_loader.c
+++ b/drivers/gpu/drm/i915/intel_huc_loader.c
@@ -291,3 +291,16 @@ void intel_huc_fini(struct drm_device *dev)
 
huc_fw->fetch_status = UC_FIRMWARE_NONE;
 }
+
+/**
+ * intel_is_huc_valid() - Check to see if the HuC is fully loaded.
+ * @dev_priv:  drm device to check.
+ *
+ * This function will return true if the guc has been loaded and
+ * has valid firmware. The simplest way of doing this is to check
+ * if the HuC has been validated, if so it must have been loaded.
+ */
+int intel_is_huc_valid(struct drm_i915_private *dev_priv)
+{
+   return ((I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED) != 0);
+}
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index bdfc688..0a9dac4 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -390,6 +390,7 @@ typedef struct drm_i915_irq_wait {
 #define I915_PARAM_HAS_POOLED_EU38
 #define I915_PARAM_MIN_EU_IN_POOL   39
 #define I915_PARAM_MMAP_GTT_VERSION 40
+#define I915_PARAM_HAS_HUC  42
 
 /* Query whether DRM_I915_GEM_EXECBUFFER2 supports user defined execution
  * priorities and the driver will attempt to execute batches in priority order.
-- 
2.7.4

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

[Intel-gfx] [PATCH 0/8] HuC Loading Patches

[Anusha Srivatsa]

These patches add HuC loading support. The userspace
patches that check for a fully loaded HuC firmware and use
it can be found at:
https://lists.freedesktop.org/archives/libva/2016-September/004554.html
https://lists.freedesktop.org/archives/libva/2016-September/004555.html
 
v2: rebased.
v3: rebased. Changed the code following the review comments.
v4: Added action_lock initialization fix provided by Arick
(Hiler Arkadiusz) to the first patch in the series- Make the
GuC fw loading helper functions general. 

Signed-off-by: Anusha Srivatsa 

Anusha Srivatsa (2):
  drm/i915/huc: Add BXT HuC Loading Support
  drm/i915/HuC: Add KBL huC loading Support

Peter Antoine (6):
  drm/i915/guc: Make the GuC fw loading helper functions general. Always
initialize action_lock
  drm/i915/huc: Unified css_header struct for GuC and HuC
  drm/i915/huc: Add HuC fw loading support
  drm/i915/huc: Add debugfs for HuC loading status check
  drm/i915/huc: Support HuC authentication
  drm/i915/get_params: Add HuC status to getparams

 drivers/gpu/drm/i915/Makefile  |   1 +
 drivers/gpu/drm/i915/i915_debugfs.c|  43 +++-
 drivers/gpu/drm/i915/i915_drv.c|   8 +
 drivers/gpu/drm/i915/i915_drv.h|   3 +
 drivers/gpu/drm/i915/i915_guc_reg.h|   3 +
 drivers/gpu/drm/i915/i915_guc_submission.c |  70 ++-
 drivers/gpu/drm/i915/intel_guc.h   |  49 +++--
 drivers/gpu/drm/i915/intel_guc_fwif.h  |  22 ++-
 drivers/gpu/drm/i915/intel_guc_loader.c| 196 +-
 drivers/gpu/drm/i915/intel_huc.h   |  43 
 drivers/gpu/drm/i915/intel_huc_loader.c| 306 +
 include/uapi/drm/i915_drm.h|   1 +
 12 files changed, 624 insertions(+), 121 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_huc.h
 create mode 100644 drivers/gpu/drm/i915/intel_huc_loader.c

-- 
2.7.4

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

[Intel-gfx] [PATCH 1/8] drm/i915/guc: Make the GuC fw loading helper functions general. Always initialize action_lock

[Anusha Srivatsa]

From: Peter Antoine 

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.

Action lock is not being initialized if the GuC submission is disabled
(i.e. i915.guc_submission=0).

host2guc_action(), which uses the action_lock can be used for
non-submission purposes, e.g. triggering HuC authentication.

Moving action_lock initialization before enablement check will allow us
to use the host2guc_action no matter whether submission is enabled or
not.

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.
v5: rebased.
v7: rebased.
v8: rebased.
v9: rebased.
v10: rebased.
v11: rebased. Added the action_lock initialization fix provided
by Arick 

Signed-off-by: Anusha Srivatsa 
Signed-off-by: Alex Dai 
Signed-off-by: Peter Antoine 
Reviewed-by: Dave Gordon 
Reviewed-by: Jeff McGee 
Reviewed-by: Carlos Santa 
Tested-by: Carlos Santa 
Signed-off-by: Arkadiusz Hiler 
---
 drivers/gpu/drm/i915/i915_debugfs.c|  12 +--
 drivers/gpu/drm/i915/i915_guc_submission.c |   7 +-
 drivers/gpu/drm/i915/intel_guc.h   |  38 +++
 drivers/gpu/drm/i915/intel_guc_loader.c| 155 +++--
 4 files changed, 108 insertions(+), 104 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 3799a12..53305a4 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2358,7 +2358,7 @@ static int i915_llc(struct seq_file *m, void *data)
 static int i915_guc_load_status_info(struct seq_file *m, void *data)
 {
struct drm_i915_private *dev_priv = node_to_i915(m->private);
-   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))
@@ -2366,15 +2366,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 4462112..9947a6d 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -1484,6 +1484,8 @@ int i915_guc_submission_init(struct drm_i915_private 
*dev_priv)
struct intel_guc *guc = _priv->guc;
struct i915_vma *vma;
 
+   mutex_init(>action_lock);
+
/* Wipe bitmap & delete client in case of reinitialisation */
bitmap_clear(guc->doorbell_bitmap, 0, GUC_MAX_DOORBELLS);
i915_guc_submission_disable(dev_priv);
@@ -1500,7 +1502,6 @@ int i915_guc_submission_init(struct drm_i915_private 
*dev_priv)
 
guc->ctx_pool_vma = vma;
ida_init(>ctx_ids);
-   mutex_init(>action_lock);
guc_log_create(guc);
guc_addon_create(guc);
 
@@ -1583,7 +1584,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;
 
gen9_disable_guc_interrupts(dev_priv);
@@ -1611,7 +1612,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 

[Intel-gfx] [bug report] drm/i915/gvt: fix deadlock in workload_thread

[Dan Carpenter]

Hello Pei Zhang,

The patch 90d27a1b180e: "drm/i915/gvt: fix deadlock in
workload_thread" from Nov 14, 2016, leads to the following static
checker warning:

drivers/gpu/drm/i915/gvt/scheduler.c:217 dispatch_workload()
warn: inconsistent returns 'mutex:_priv->drm.struct_mutex'.

drivers/gpu/drm/i915/gvt/scheduler.c
   161  static int dispatch_workload(struct intel_vgpu_workload *workload)
   162  {
   163  int ring_id = workload->ring_id;
   164  struct i915_gem_context *shadow_ctx = 
workload->vgpu->shadow_ctx;
   165  struct drm_i915_private *dev_priv = 
workload->vgpu->gvt->dev_priv;
   166  struct drm_i915_gem_request *rq;
   167  int ret;
   168  
   169  gvt_dbg_sched("ring id %d prepare to dispatch workload %p\n",
   170  ring_id, workload);
   171  
   172  shadow_ctx->desc_template = workload->ctx_desc.addressing_mode 
<<
   173  GEN8_CTX_ADDRESSING_MODE_SHIFT;
   174  
   175  mutex_lock(_priv->drm.struct_mutex);
   176  
   177  rq = i915_gem_request_alloc(dev_priv->engine[ring_id], 
shadow_ctx);
   178  if (IS_ERR(rq)) {
   179  gvt_err("fail to allocate gem request\n");
   180  workload->status = PTR_ERR(rq);
   181  return workload->status;

We're holding the lock here, which is obviously a bug.  But also should
we goto out?  I always thought that functions with an "out" label were
future proof?

   182  }
   183  
   184  gvt_dbg_sched("ring id %d get i915 gem request %p\n", ring_id, 
rq);
   185  
   186  workload->req = i915_gem_request_get(rq);
   187  
   188  ret = intel_gvt_scan_and_shadow_workload(workload);
   189  if (ret)
   190  goto out;
   191  
   192  ret = intel_gvt_scan_and_shadow_wa_ctx(>wa_ctx);
   193  if (ret)
   194  goto out;
   195  

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

Re: [Intel-gfx] [PATCH 0/3] drm/i915: atomic_cdclk_freq fixes

[Ville Syrjälä]

On Mon, Nov 14, 2016 at 06:35:08PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> My little fix for populating intel_state->cdclk with
> dev_priv->atomic_cdclk_freq became a little meatier after I realized
> that we really need to protect it with what is essentially a crtc
> rwlock. That is, writers need to hold all the crtc locks, whereas
> readers need to hold at least one.
> 
> Ville Syrjälä (3):
>   drm/i915: Fix cdclk vs. dev_cdclk mess when not recomputing things
>   drm/i915: Protect dev_priv->atomic_cdclk_freq with all the crtc locks
>   drm/i915: Simplify error handling in intel_modeset_all_pipes()

Entire series pushed to dinq. Thanks for the reviews.

> 
>  drivers/gpu/drm/i915/i915_drv.h  |  9 +-
>  drivers/gpu/drm/i915/intel_display.c | 60 
> 
>  2 files changed, 55 insertions(+), 14 deletions(-)
> 
> -- 
> 2.7.4

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

Re: [Intel-gfx] [PATCH] drm/i915/bxt: Correct dual-link MIPI port control.

[Ville Syrjälä]

On Tue, Nov 22, 2016 at 03:00:14PM +0200, Ville Syrjälä wrote:
> On Mon, Nov 21, 2016 at 02:24:06PM -0800, Bob Paauwe wrote:
> > For BXT, there is only one bit that enables/disables dual-link mode
> > and not different bits depending on which pipe is being used.
> > 
> > Signed-off-by: Bob Paauwe 
> > ---
> >  drivers/gpu/drm/i915/intel_dsi.c | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
> > b/drivers/gpu/drm/i915/intel_dsi.c
> > index 4e0d025..a35c141 100644
> > --- a/drivers/gpu/drm/i915/intel_dsi.c
> > +++ b/drivers/gpu/drm/i915/intel_dsi.c
> > @@ -476,7 +476,10 @@ static void intel_dsi_port_enable(struct intel_encoder 
> > *encoder)
> > if (intel_dsi->ports == (BIT(PORT_A) | BIT(PORT_C))) {
> > temp |= (intel_dsi->dual_link - 1)
> > << DUAL_LINK_MODE_SHIFT;
> > -   temp |= intel_crtc->pipe ?
> > +   if (IS_BROXTON(dev_priv))
> > +   temp |= LANE_CONFIGURATION_DUAL_LINK_A;
> > +   else
> > +   temp |= intel_crtc->pipe ?
> > LANE_CONFIGURATION_DUAL_LINK_B :
> > LANE_CONFIGURATION_DUAL_LINK_A;
> 
> Reviewed-by: Ville Syrjälä 

And pushed to dinq. Thanks for the patch.

-- 
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 0/9] drm/i915: Add a per-pipe plane identifier enum (v2)

[Ville Syrjälä]

On Tue, Nov 22, 2016 at 06:01:55PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> I ended up tweaking quite a few of the patches (and even adding a new one)
> based on Paulo's review, so figured I'd repost the entire thing.
> 
> I didn't do the _ID_ rename thing, at least not yet. I'll have to
> think about it more if I could come up with some nice way to deal
> with the per-pipe id vs. the A/B/C plane id.
> 
> Anyways, enough of these got r-bs so that I can at least move
> forward with VLV/CHV watermark rewrite #4 now.
> 
> Ville Syrjälä (9):
>   drm/i915: Add per-pipe plane identifier
>   drm/i915: Add crtc->plane_ids_mask
>   drm/i915: Use enum plane_id in SKL wm code
>   drm/i915: Use enum plane_id in SKL plane code
>   drm/i915: Use enum plane_id in VLV/CHV sprite code
>   drm/i915: Use enum plane_id in VLV/CHV wm code

Pushed upto here. Thanks for the reviews.

>   drm/i915: s/plane/plane_id/ in skl+ plane register defines
>   drm/i915: Don't populate plane->plane for cursors and sprites
>   drm/i915: Rename the local 'plane' variable to 'plane_id' in primary
> plane code
> 
>  drivers/gpu/drm/i915/i915_drv.h  |  30 -
>  drivers/gpu/drm/i915/i915_reg.h  | 104 +++---
>  drivers/gpu/drm/i915/intel_display.c |  96 ++---
>  drivers/gpu/drm/i915/intel_drv.h |   6 +-
>  drivers/gpu/drm/i915/intel_pm.c  | 253 
> ---
>  drivers/gpu/drm/i915/intel_sprite.c  | 118 
>  6 files changed, 304 insertions(+), 303 deletions(-)
> 
> -- 
> 2.7.4

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

Re: [Intel-gfx] [PATCH] drm/i915: Make skl_write_{plane, cursor}_wm() static

[Ville Syrjälä]

On Wed, Nov 23, 2016 at 11:15:45AM +0100, Maarten Lankhorst wrote:
> Op 22-11-16 om 21:28 schreef Lyude Paul:
> > Reviewed-by: Lyude 
> >
> > On Tue, 2016-11-22 at 22:21 +0200, ville.syrj...@linux.intel.com wrote:
> >> From: Ville Syrjälä 
> >>
> >> Someone forgot to make skl_write_{plane,cursor}_wm() static when
> >> removing the prototypes from the header. Sparse isn't pleased.
> >>
> >> Cc: Maarten Lankhorst 
> >> Cc: Lyude 
> >> Cc: Matt Roper 
> >> Fixes: e62929b3f628 ("drm/i915/gen9+: Program watermarks as a
> >> separate step during evasion, v3.")
> >> Signed-off-by: Ville Syrjälä 
> >> ---
> >>  drivers/gpu/drm/i915/intel_pm.c | 14 +++---
> >>  1 file changed, 7 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_pm.c
> >> b/drivers/gpu/drm/i915/intel_pm.c
> >> index bbb1eaf1e6db..d67974eb127a 100644
> >> --- a/drivers/gpu/drm/i915/intel_pm.c
> >> +++ b/drivers/gpu/drm/i915/intel_pm.c
> >> @@ -3851,10 +3851,10 @@ static void skl_write_wm_level(struct
> >> drm_i915_private *dev_priv,
> >>I915_WRITE(reg, val);
> >>  }
> >>  
> >> -void skl_write_plane_wm(struct intel_crtc *intel_crtc,
> >> -  const struct skl_plane_wm *wm,
> >> -  const struct skl_ddb_allocation *ddb,
> >> -  int plane)
> >> +static void skl_write_plane_wm(struct intel_crtc *intel_crtc,
> >> + const struct skl_plane_wm *wm,
> >> + const struct skl_ddb_allocation *ddb,
> >> + int plane)
> >>  {
> >>struct drm_crtc *crtc = _crtc->base;
> >>struct drm_device *dev = crtc->dev;
> >> @@ -3875,9 +3875,9 @@ void skl_write_plane_wm(struct intel_crtc
> >> *intel_crtc,
> >>>y_plane[pipe][plane]);
> >>  }
> >>  
> >> -void skl_write_cursor_wm(struct intel_crtc *intel_crtc,
> >> -   const struct skl_plane_wm *wm,
> >> -   const struct skl_ddb_allocation *ddb)
> >> +static void skl_write_cursor_wm(struct intel_crtc *intel_crtc,
> >> +  const struct skl_plane_wm *wm,
> >> +  const struct skl_ddb_allocation
> >> *ddb)
> >>  {
> >>struct drm_crtc *crtc = _crtc->base;
> >>struct drm_device *dev = crtc->dev;
> 
> Mea-culpa!
> 
> Reviewed-by: Maarten Lankhorst 

Pushed to dinq. Thanks for the reviews.

-- 
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 RFC] drm: Add a new connector atomic property for link status

[Manasi Navare]

On Wed, Nov 23, 2016 at 11:00:59AM +0100, Daniel Vetter wrote:
> On Tue, Nov 22, 2016 at 05:30:21PM -0800, Manasi Navare wrote:
> > This is RFC patch for adding a connector link-status property
> > and making it atomic by adding it to the drm_connector_state.
> > This is to make sure its wired properly in drm_atomic_connector_set_property
> > and drm_atomic_connector_get_property functions.
> > 
> > Cc: Jani Nikula 
> > Cc: Daniel Vetter 
> > Cc: Ville Syrjala 
> > Cc: Chris Wilson 
> > Signed-off-by: Manasi Navare 
> > ---
> >  drivers/gpu/drm/drm_atomic.c|  5 
> >  drivers/gpu/drm/drm_connector.c | 65 
> > +++--
> >  include/drm/drm_connector.h | 12 +++-
> >  include/drm/drm_mode_config.h   |  5 
> >  include/uapi/drm/drm_mode.h |  4 +++
> >  5 files changed, 88 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 89737e4..644d19f 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -1087,6 +1087,9 @@ int drm_atomic_connector_set_property(struct 
> > drm_connector *connector,
> >  * now?) atomic writes to DPMS property:
> >  */
> > return -EINVAL;
> > +   } else if (property == config->link_status_property) {
> > +   state->link_status = val;
> > +   return 0;
> > } else if (connector->funcs->atomic_set_property) {
> > return connector->funcs->atomic_set_property(connector,
> > state, property, val);
> > @@ -1135,6 +1138,8 @@ static void drm_atomic_connector_print_state(struct 
> > drm_printer *p,
> > *val = (state->crtc) ? state->crtc->base.id : 0;
> > } else if (property == config->dpms_property) {
> > *val = connector->dpms;
> > +   } else if (property == config->link_status_property) {
> > +   *val = state->link_status;
> > } else if (connector->funcs->atomic_get_property) {
> > return connector->funcs->atomic_get_property(connector,
> > state, property, val);
> > diff --git a/drivers/gpu/drm/drm_connector.c 
> > b/drivers/gpu/drm/drm_connector.c
> > index 5a45262..4576c9f 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -243,6 +243,10 @@ int drm_connector_init(struct drm_device *dev,
> > drm_object_attach_property(>base,
> >   config->dpms_property, 0);
> >  
> > +   drm_object_attach_property(>base,
> > +  config->link_status_property,
> > +  0);
> > +
> > if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
> > drm_object_attach_property(>base, 
> > config->prop_crtc_id, 0);
> > }
> > @@ -506,6 +510,12 @@ const char *drm_get_subpixel_order_name(enum 
> > subpixel_order order)
> >  };
> >  DRM_ENUM_NAME_FN(drm_get_dpms_name, drm_dpms_enum_list)
> >  
> > +static const struct drm_prop_enum_list drm_link_status_enum_list[] = {
> > +   { DRM_MODE_LINK_STATUS_GOOD, "Good" },
> > +   { DRM_MODE_LINK_STATUS_BAD, "Bad" },
> > +};
> > +DRM_ENUM_NAME_FN(drm_get_link_status_name, drm_link_status_enum_list)
> > +
> >  /**
> >   * drm_display_info_set_bus_formats - set the supported bus formats
> >   * @info: display info to store bus formats in
> > @@ -616,7 +626,7 @@ int drm_display_info_set_bus_formats(struct 
> > drm_display_info *info,
> >   * path property the MST manager created. Userspace cannot change 
> > this
> >   * property.
> >   * TILE:
> > - * Connector tile group property to indicate how a set of DRM 
> > connector
> > + *  Connector tile group property to indicate how a set of DRM 
> > connector
> >   * compose together into one logical screen. This is used by both 
> > high-res
> >   * external screens (often only using a single cable, but exposing 
> > multiple
> >   * DP MST sinks), or high-res integrated panels (like dual-link 
> > DSI) which
> > @@ -625,7 +635,14 @@ int drm_display_info_set_bus_formats(struct 
> > drm_display_info *info,
> >   * tiling and virtualize both _crtc and _plane if needed. 
> > Drivers
> >   * should update this value using 
> > drm_mode_connector_set_tile_property().
> >   * Userspace cannot change this property.
> > - *
> > + * link-status:
> > + *  Connector link-status property to indicate the status of link 
> > during
> > + *  the modeset. The default value of link-status is "GOOD". If 
> > something
> > + *  fails during modeset, the kernel driver can set this to "BAD", 
> > prune
> > + *  the mode list based on new link parameters and send a hotplug 
> > uevent
> > + *  to notify userspace to re-check the valid modes through 
> > 

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Make GPU pages movable

[Hugh Dickins]

On Wed, 23 Nov 2016, Daniel Vetter wrote:
> On Tue, Nov 22, 2016 at 09:26:11PM -0800, Hugh Dickins wrote:
> > On Tue, 22 Nov 2016, Matthew Auld wrote:
> > > On 9 November 2016 at 18:36, Hugh Dickins  wrote:
> > > > On Wed, 9 Nov 2016, Daniel Vetter wrote:
> > > >>
> > > >> Hi all -mm folks!
> > > >>
> > > >> Any feedback on these two? It's kinda an intermediate step towards a
> > > >> full-blown gemfs, and I think useful for that. Or do we need to go
> > > >> directly to our own backing storage thing? Aside from ack/nack from 
> > > >> -mm I
> > > >> think this is ready for merging.
> > > >
> > > > I'm currently considering them at last: will report back later.
> > > >
> > > > Full-blown gemfs does not come in here, of course; but let me
> > > > fire a warning shot since you mention it: if it's going to use swap,
> > > > then we shall probably have to nak it in favour of continuing to use
> > > > infrastructure from mm/shmem.c.  I very much understand why you would
> > > > love to avoid that dependence, but I doubt it can be safely bypassed.
> > >
> > > Could you please elaborate on what specifically you don't like about
> > > gemfs implementing swap, just to make sure I'm following?
> > 
> > If we're talking about swap as implemented in mm/swapfile.c, and
> > managed for tmpfs mainly through shmem_getpage_gfp(): that's slippery
> > stuff, private to mm, and I would not want such trickiness duplicated
> > somewhere down in drivers/gpu/drm, where mm developers and drm developers
> > will keep on forgetting to keep it working correctly.
> > 
> > But you write of gemfs "implementing" swap (and I see Daniel wrote of
> > "our own backing storage"): perhaps you intend a disk or slow-mem file
> > of your own, dedicated to paging gemfs objects according to your own
> > rules, poked from memory reclaim via a shrinker.  I certainly don't
> > have the same quick objection to that: it may be a good way forward,
> > though I'm not at all sure (and would prefer a name distinct from
> > swap, so we wouldn't get confused - maybe gemswap).
> 
> "our backing storage" was from the pov of the gpu, which is just
> memory (and then normal swap). I think that's exactly the part you don't
> like ;-)

Yes ;) but never mind, reassuring answer below...

> 
> Anwyway, objections noted, we'll go and beef up the interfaces exposed by
> shmem in the style of this patch series here. What I'll expect in the
> future beyong the migrate callback so we can unpin pages is asking shmem
> to move the pages around to a different numa node, and also asking for
> hugepages (if available). Thanks a lot for your feedback meanwhile.

Migration callback, NUMA improvements, hugepages: all are reasonable
things to be asking of shmem.  I expect we'll have some to and fro on
how best to fit whatever interface you want with how those are already
handled, but none of those requests is reason to replace shmem by an
independently backed gemfs.

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

Re: [Intel-gfx] [PATCH 3/5] drm/i915/bxt: Added _DSM call to set HPD_CTL.

[Ville Syrjälä]

On Wed, Nov 23, 2016 at 09:48:25PM +0530, Animesh Manna wrote:
> _DSM is added to program HPD_CTL(0x1094) register
> of PMC from i915 driver which will be called
> based on driver feature flag. PMC hpd control register
> programming will enable PMC to get hpd interrupt
> during dc9.
> 
> Signed-off-by: Animesh Manna 
> ---
>  drivers/gpu/drm/i915/intel_acpi.c | 44 
> ---
>  1 file changed, 37 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_acpi.c 
> b/drivers/gpu/drm/i915/intel_acpi.c
> index 8c878ab..15d3b84 100755
> --- a/drivers/gpu/drm/i915/intel_acpi.c
> +++ b/drivers/gpu/drm/i915/intel_acpi.c
> @@ -10,6 +10,8 @@
>  
>  #define INTEL_DSM_REVISION_ID 1 /* For Calpella anyway... */
>  #define INTEL_DSM_FN_PLATFORM_MUX_INFO 1 /* No args */
> +#define INTEL_DSM_SET_HPD_WAKEUP 17
> +#define HPD_WAKEUP_EN_VAL 0xFCF0
>  
>  static struct intel_dsm_priv {
>   acpi_handle dhandle;
> @@ -118,6 +120,25 @@ static void intel_dsm_platform_mux_info(void)
>   ACPI_FREE(pkg);
>  }
>  
> +static void intel_dsm_set_hpd_wakeup(u8 *guid)
> +{
> + union acpi_object *obj;
> + union acpi_object argv4 = {
> + .integer.type = ACPI_TYPE_INTEGER,
> + .integer.value = HPD_WAKEUP_EN_VAL,
> + };
> +
> + obj = acpi_evaluate_dsm_typed(intel_dsm_priv.dhandle, guid,
> + INTEL_DSM_REVISION_ID, INTEL_DSM_SET_HPD_WAKEUP,
> + , ACPI_TYPE_INTEGER);
> +
> + if (!obj)
> + DRM_DEBUG_DRIVER("failed to evaluate _DSM\n");
> +
> + ACPI_FREE(obj);
> +}
> +
> +
>  static bool intel_dsm_pci_probe(struct pci_dev *pdev)
>  {
>   acpi_handle dhandle;
> @@ -134,14 +155,23 @@ static bool intel_dsm_pci_probe(struct pci_dev *pdev)
>   else
>   guid = intel_dsm_guid;
>  
> - if (!acpi_check_dsm(dhandle, guid, INTEL_DSM_REVISION_ID,
> - 1 << INTEL_DSM_FN_PLATFORM_MUX_INFO)) {
> - DRM_DEBUG_KMS("no _DSM method for intel device\n");
> - return false;
> - }
> -
>   intel_dsm_priv.dhandle = dhandle;
> - intel_dsm_platform_mux_info();
> +
> + if (acpi_check_dsm(dhandle, guid, INTEL_DSM_REVISION_ID,
> + 1 << INTEL_DSM_FN_PLATFORM_MUX_INFO))
> + intel_dsm_platform_mux_info();
> + else
> + DRM_DEBUG_KMS("no _DSM method for mux-info\n");
> +
> + /* Need to ensure vbt parsing is completed. */

Eh?

> + if (dev_priv->vbt.hpd_wakeup_enabled &&
> + acpi_check_dsm(dhandle, guid, INTEL_DSM_REVISION_ID,
> + 1 << INTEL_DSM_SET_HPD_WAKEUP))
> + intel_dsm_set_hpd_wakeup(guid);

So we're permanently routing hpds to the pcu? Won't that mess up
stuff like short pulse detection?

I was expecting that we'd switch between the PCU and not during
runtime suspend/resume.

> + else {
> + dev_priv->vbt.hpd_wakeup_enabled = false;
> + DRM_DEBUG_KMS("no _DSM method for hpd-enabling\n");
> + }
>  
>   return true;
>  }
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Intel-gfx] ✗ Fi.CI.BAT: warning for HPD support during suspend for BXT/APL.

[Patchwork]

== Series Details ==

Series: HPD support during suspend for BXT/APL.
URL   : https://patchwork.freedesktop.org/series/15833/
State : warning

== Summary ==

Series 15833v1 HPD support during suspend for BXT/APL.
https://patchwork.freedesktop.org/api/1.0/series/15833/revisions/1/mbox/

Test drv_module_reload_basic:
pass   -> DMESG-WARN (fi-bxt-t5700)
Test pm_rpm:
Subgroup basic-pci-d3-state:
pass   -> DMESG-WARN (fi-bxt-t5700)
Subgroup basic-rte:
pass   -> DMESG-WARN (fi-bxt-t5700)
Test prime_vgem:
Subgroup basic-fence-flip:
pass   -> DMESG-WARN (fi-bxt-t5700)

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

01896e61d9cc0cad08e19990cd095cdf679f6142 drm-intel-nightly: 
2016y-11m-23d-14h-45m-53s UTC integration manifest
acc7df4 drm/i915: Enable HPD interrupts with master ctl interrupt
eb7a5df drm/i915/bxt: Block D3 during suspend.
8834d93 drm/i915/bxt: Added _DSM call to set HPD_CTL.
1d08e3f drm/i915/bxt: VBT changes for hpd as wakeup feature
f0e96b6 drm/i915/bxt: Corrected the guid for bxt.

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/perf: Wrap 64bit divides in do_div() (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/perf: Wrap 64bit divides in do_div() (rev3)
URL   : https://patchwork.freedesktop.org/series/15769/
State : success

== Summary ==

Series 15769v3 drm/i915/perf: Wrap 64bit divides in do_div()
https://patchwork.freedesktop.org/api/1.0/series/15769/revisions/3/mbox/


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

01896e61d9cc0cad08e19990cd095cdf679f6142 drm-intel-nightly: 
2016y-11m-23d-14h-45m-53s UTC integration manifest
f9e1734 drm/i915/perf: Wrap 64bit divides in do_div()

== Logs ==

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

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Enable HPD interrupts with master ctl interrupt

[Ville Syrjälä]

On Wed, Nov 23, 2016 at 09:48:27PM +0530, Animesh Manna wrote:
> While suspending the device hpd related interrupts are enabled
> to get the interrupt when device is in suspend state.
> 
> Though display is in DC9 but system can be in S0 or S0i3 state.
> Hot plug during S0 state will generate de_port_interrupt but if
> system is in S0i3 state then display driver will get hotplug
> interrupt as pcu_hpd_interrupt which will come via pmc. So
> added the interrupt handling for pcu hpd interrupt.
> 
> Signed-off-by: Animesh Manna 
> Signed-off-by: A.Sunil Kamath 
> ---
>  drivers/gpu/drm/i915/i915_irq.c | 56 
> ++---
>  drivers/gpu/drm/i915/i915_reg.h | 12 +
>  2 files changed, 65 insertions(+), 3 deletions(-)
>  mode change 100644 => 100755 drivers/gpu/drm/i915/i915_irq.c
> 
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> old mode 100644
> new mode 100755
> index cb8a75f..2f9b604
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -110,9 +110,9 @@
>  
>  /* BXT hpd list */
>  static const u32 hpd_bxt[HPD_NUM_PINS] = {
> - [HPD_PORT_A] = BXT_DE_PORT_HP_DDIA,
> - [HPD_PORT_B] = BXT_DE_PORT_HP_DDIB,
> - [HPD_PORT_C] = BXT_DE_PORT_HP_DDIC
> + [HPD_PORT_A] = (BXT_DE_PORT_HP_DDIA | BXT_PCU_DC9_HP_DDIA),
> + [HPD_PORT_B] = (BXT_DE_PORT_HP_DDIB | BXT_PCU_DC9_HP_DDIB),
> + [HPD_PORT_C] = (BXT_DE_PORT_HP_DDIC | BXT_PCU_DC9_HP_DDIC)

hpd_bxt_pcu[]

>  };
>  
>  /* IIR can theoretically queue up two events. Be paranoid. */
> @@ -2463,6 +2463,24 @@ static void bxt_hpd_irq_handler(struct 
> drm_i915_private *dev_priv,
>   DRM_ERROR("The master control interrupt lied (DE 
> PORT)!\n");
>   }
>  
> + if (master_ctl & GEN8_PCU_IRQ) {
> + iir = I915_READ(GEN8_PCU_IIR);
> + if (iir) {
> + u32 tmp_mask;
> +

Please add a proper pcu irq ack/handler pair. I actually have such a
thing sitting on a branch:

git://github.com/vsyrjala/linux.git pcode_irq

> + I915_WRITE(GEN8_PCU_IIR, iir);
> + ret = IRQ_HANDLED;
> + if (IS_BROXTON(dev_priv)) {
> + tmp_mask = iir & BXT_PCU_DC9_HOTPLUG_MASK;
> + if (tmp_mask)
> + bxt_hpd_irq_handler(dev_priv, tmp_mask,
> + hpd_bxt);

Umm. Does the PCH_HOTPLUG reg actually work in this "hpd redirected to
pcu" state? As in are we going to detect long vs. short pulses correctly
if you just use bxt_hpd_irq_handler()?

> + } else
> + DRM_ERROR("Unexpected PCU interrupt\n");
> + } else
> + DRM_ERROR("The master control interrupt lied (PCU)!\n");
> + }
> +
>   for_each_pipe(dev_priv, pipe) {
>   u32 flip_done, fault_errors;
>  
> @@ -4294,6 +4312,19 @@ void intel_irq_uninstall(struct drm_i915_private 
> *dev_priv)
>   dev_priv->pm.irqs_enabled = false;
>  }
>  
> +static void bxt_enable_pcu_interrupt(struct drm_i915_private *dev_priv)
> +{
> + u32 de_pcu_hpd_enable_mask, de_pcu_imr, de_pcu_ier;
> +
> + de_pcu_hpd_enable_mask = GEN9_DE_PCU_PORTA_HOTPLUG |
> + GEN9_DE_PCU_PORTB_HOTPLUG |
> + GEN9_DE_PCU_PORTC_HOTPLUG;
> +
> + de_pcu_imr = (I915_READ(GEN8_PCU_IMR) & 0x0);
> + de_pcu_ier = (I915_READ(GEN8_PCU_IER) | de_pcu_hpd_enable_mask);

You'll want a bdw_update_pcu_irq() or some such thing.

> + GEN5_IRQ_INIT(GEN8_PCU_, de_pcu_imr, de_pcu_ier);
> +}
> +
>  /**
>   * intel_runtime_pm_disable_interrupts - runtime interrupt disabling
>   * @dev_priv: i915 device instance
> @@ -4303,8 +4334,27 @@ void intel_irq_uninstall(struct drm_i915_private 
> *dev_priv)
>   */
>  void intel_runtime_pm_disable_interrupts(struct drm_i915_private *dev_priv)
>  {
> + unsigned long flags = 0;
> +
>   dev_priv->drm.driver->irq_uninstall(_priv->drm);
>   dev_priv->pm.irqs_enabled = false;
> +
> + if (IS_BROXTON(dev_priv) && dev_priv->vbt.hpd_wakeup_enabled) {
> +
> + /* Enable HPD related interrupts during DC9 for HPD wakeup */
> +
> + I915_WRITE(GEN8_MASTER_IRQ, GEN8_MASTER_IRQ_CONTROL);
> + POSTING_READ(GEN8_MASTER_IRQ);
> +
> + spin_lock_irqsave(_priv->irq_lock, flags);
> + if (dev_priv->display.hpd_irq_setup)
> + dev_priv->display.hpd_irq_setup(dev_priv);
> + spin_unlock_irqrestore(_priv->irq_lock, flags);
> +
> + bxt_enable_pcu_interrupt(dev_priv);
> +
> + dev_priv->pm.irqs_enabled = true;
> + }
>   synchronize_irq(dev_priv->drm.irq);
>  }
>  
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 3361d7f..df89025 100644
> --- 

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Enable HPD interrupts with master ctl interrupt

[Imre Deak]

On Wed, 2016-11-23 at 21:48 +0530, Animesh Manna wrote:
> While suspending the device hpd related interrupts are enabled
> to get the interrupt when device is in suspend state.
> 
> Though display is in DC9 but system can be in S0 or S0i3 state.
> Hot plug during S0 state will generate de_port_interrupt but if
> system is in S0i3 state then display driver will get hotplug
> interrupt as pcu_hpd_interrupt which will come via pmc. So
> added the interrupt handling for pcu hpd interrupt.
> 
> Signed-off-by: Animesh Manna 
> Signed-off-by: A.Sunil Kamath 
> ---
>  drivers/gpu/drm/i915/i915_irq.c | 56 
> ++---
>  drivers/gpu/drm/i915/i915_reg.h | 12 +
>  2 files changed, 65 insertions(+), 3 deletions(-)
>  mode change 100644 => 100755 drivers/gpu/drm/i915/i915_irq.c
> 
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> old mode 100644
> new mode 100755
> index cb8a75f..2f9b604
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -110,9 +110,9 @@
>  
>  /* BXT hpd list */
>  static const u32 hpd_bxt[HPD_NUM_PINS] = {
> - [HPD_PORT_A] = BXT_DE_PORT_HP_DDIA,
> - [HPD_PORT_B] = BXT_DE_PORT_HP_DDIB,
> - [HPD_PORT_C] = BXT_DE_PORT_HP_DDIC
> + [HPD_PORT_A] = (BXT_DE_PORT_HP_DDIA | BXT_PCU_DC9_HP_DDIA),
> + [HPD_PORT_B] = (BXT_DE_PORT_HP_DDIB | BXT_PCU_DC9_HP_DDIB),
> + [HPD_PORT_C] = (BXT_DE_PORT_HP_DDIC | BXT_PCU_DC9_HP_DDIC)

These are bits programmed to GEN8_DE_PORT_*, so adding the PCU bits
here is bogus.

>  };
>  
>  /* IIR can theoretically queue up two events. Be paranoid. */
> @@ -2463,6 +2463,24 @@ static void bxt_hpd_irq_handler(struct 
> drm_i915_private *dev_priv,
>   DRM_ERROR("The master control interrupt lied (DE 
> PORT)!\n");
>   }
>  
> + if (master_ctl & GEN8_PCU_IRQ) {
> + iir = I915_READ(GEN8_PCU_IIR);
> + if (iir) {
> + u32 tmp_mask;
> +
> + I915_WRITE(GEN8_PCU_IIR, iir);
> + ret = IRQ_HANDLED;
> + if (IS_BROXTON(dev_priv)) {
> + tmp_mask = iir & BXT_PCU_DC9_HOTPLUG_MASK;
> + if (tmp_mask)
> + bxt_hpd_irq_handler(dev_priv, tmp_mask,
> + hpd_bxt);
> + } else
> + DRM_ERROR("Unexpected PCU interrupt\n");
> + } else
> + DRM_ERROR("The master control interrupt lied (PCU)!\n");
> + }
> +
>   for_each_pipe(dev_priv, pipe) {
>   u32 flip_done, fault_errors;
>  
> @@ -4294,6 +4312,19 @@ void intel_irq_uninstall(struct drm_i915_private 
> *dev_priv)
>   dev_priv->pm.irqs_enabled = false;
>  }
>  
> +static void bxt_enable_pcu_interrupt(struct drm_i915_private *dev_priv)
> +{
> + u32 de_pcu_hpd_enable_mask, de_pcu_imr, de_pcu_ier;
> +
> + de_pcu_hpd_enable_mask = GEN9_DE_PCU_PORTA_HOTPLUG |
> + GEN9_DE_PCU_PORTB_HOTPLUG |
> + GEN9_DE_PCU_PORTC_HOTPLUG;
> +
> + de_pcu_imr = (I915_READ(GEN8_PCU_IMR) & 0x0);

Typo.

> + de_pcu_ier = (I915_READ(GEN8_PCU_IER) | de_pcu_hpd_enable_mask);
> + GEN5_IRQ_INIT(GEN8_PCU_, de_pcu_imr, de_pcu_ier);
> +}
> +
>  /**
>   * intel_runtime_pm_disable_interrupts - runtime interrupt disabling
>   * @dev_priv: i915 device instance
> @@ -4303,8 +4334,27 @@ void intel_irq_uninstall(struct drm_i915_private 
> *dev_priv)
>   */
>  void intel_runtime_pm_disable_interrupts(struct drm_i915_private *dev_priv)
>  {
> + unsigned long flags = 0;
> +
>   dev_priv->drm.driver->irq_uninstall(_priv->drm);
>   dev_priv->pm.irqs_enabled = false;
> +
> + if (IS_BROXTON(dev_priv) && dev_priv->vbt.hpd_wakeup_enabled) {
> +
> + /* Enable HPD related interrupts during DC9 for HPD wakeup */
> +
> + I915_WRITE(GEN8_MASTER_IRQ, GEN8_MASTER_IRQ_CONTROL);
> + POSTING_READ(GEN8_MASTER_IRQ);
> +
> + spin_lock_irqsave(_priv->irq_lock, flags);
> + if (dev_priv->display.hpd_irq_setup)
> + dev_priv->display.hpd_irq_setup(dev_priv);
> + spin_unlock_irqrestore(_priv->irq_lock, flags);
> +
> + bxt_enable_pcu_interrupt(dev_priv);

The lock should be around the whole IRQ programming sequence.

> +
> + dev_priv->pm.irqs_enabled = true;
> + }
>   synchronize_irq(dev_priv->drm.irq);

This should come before the IRQ enabling.

>  }
>  
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 3361d7f..df89025 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6030,6 +6030,18 @@ enum {
>  #define GEN8_PCU_IIR _MMIO(0x444e8)
>  #define GEN8_PCU_IER _MMIO(0x444ec)
>  
> +/* BXT PCU DC9 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Pass dev_priv to intel_setup_outputs() (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Pass dev_priv to intel_setup_outputs() (rev2)
URL   : https://patchwork.freedesktop.org/series/15820/
State : success

== Summary ==

Series 15820v2 drm/i915: Pass dev_priv to intel_setup_outputs()
https://patchwork.freedesktop.org/api/1.0/series/15820/revisions/2/mbox/


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

01896e61d9cc0cad08e19990cd095cdf679f6142 drm-intel-nightly: 
2016y-11m-23d-14h-45m-53s UTC integration manifest
0832b12 drm/i915: Pass dev_priv to intel_setup_outputs()

== Logs ==

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

Re: [Intel-gfx] [PATCH 1/5] drm/i915/bxt: Corrected the guid for bxt.

[Chris Wilson]

On Wed, Nov 23, 2016 at 09:48:23PM +0530, Animesh Manna wrote:
> Guid is changed for bxt platform, so corrected the guid for bxt.
> 
> v1: Initial version as RFC.
> 
> v2: Based on review comment from Jani and David,
> have kept guid as binary format.
> 
> Signed-off-by: Ananth Krishna R 
> Signed-off-by: Bharath K Veera 
> Signed-off-by: Animesh Manna 
> ---
>  drivers/gpu/drm/i915/intel_acpi.c | 20 ++--
>  1 file changed, 18 insertions(+), 2 deletions(-)
>  mode change 100644 => 100755 drivers/gpu/drm/i915/intel_acpi.c
> 
> diff --git a/drivers/gpu/drm/i915/intel_acpi.c 
> b/drivers/gpu/drm/i915/intel_acpi.c
> old mode 100644
> new mode 100755

3 people handled this patch and none complained about making
intel_acpi.c executable? What does happen when you try to execute it?

> index eb638a1..8c878ab
> --- a/drivers/gpu/drm/i915/intel_acpi.c
> +++ b/drivers/gpu/drm/i915/intel_acpi.c
> @@ -15,7 +15,7 @@
>   acpi_handle dhandle;
>  } intel_dsm_priv;
>  
> -static const u8 intel_dsm_guid[] = {
> +static u8 intel_dsm_guid[] = {

Why drop the const?

>   0xd3, 0x73, 0xd8, 0x7e,
>   0xd0, 0xc2,
>   0x4f, 0x4e,
> @@ -23,6 +23,14 @@
>   0x0f, 0x13, 0x17, 0xb0, 0x1c, 0x2c
>  };
>  
> +static u8 intel_dsm_guid_bxt[] = {

Missing const.

> + 0xc6, 0x41, 0x5b, 0x3e,
> + 0x1d, 0xeb,
> + 0x60, 0x42,
> + 0x9d, 0x15,
> + 0xc7, 0x1f, 0xba, 0xda, 0xe4, 0x14
> +};
> +
>  static char *intel_dsm_port_name(u8 id)
>  {
>   switch (id) {
> @@ -113,12 +121,20 @@ static void intel_dsm_platform_mux_info(void)
>  static bool intel_dsm_pci_probe(struct pci_dev *pdev)
>  {
>   acpi_handle dhandle;
> + struct drm_device *dev = pci_get_drvdata(pdev);
> + struct drm_i915_private *dev_priv = dev->dev_private;

dev == dev_priv, just a rose by another name. Use to_i915();

> + u8 *guid;

Missing const.

>  
>   dhandle = ACPI_HANDLE(>dev);
>   if (!dhandle)
>   return false;
>  
> - if (!acpi_check_dsm(dhandle, intel_dsm_guid, INTEL_DSM_REVISION_ID,
> + if (IS_BROXTON(dev_priv))
> + guid = intel_dsm_guid_bxt;
> + else
> + guid = intel_dsm_guid;
> +
> + if (!acpi_check_dsm(dhandle, guid, INTEL_DSM_REVISION_ID,
>   1 << INTEL_DSM_FN_PLATFORM_MUX_INFO)) {
>   DRM_DEBUG_KMS("no _DSM method for intel device\n");
>   return false;
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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] [i-g-t PATCH v11 2/5] lib: add igt_dummyload

[Chris Wilson]

On Wed, Nov 23, 2016 at 05:53:50PM +0200, Abdiel Janulgue wrote:
> +static int at_exit_drm_fd = -1;
> +
> +static void quiescent_gpu_at_exit(int sig)
> +{
> + if (at_exit_drm_fd < 0)
> + return;
> +
> + gem_quiescent_gpu(at_exit_drm_fd);
> + at_exit_drm_fd = -1;
> +}
> +
> +/**
> + * igt_spin_batch_new:
> + * @fd: open i915 drm file descriptor
> + * @engine: Ring to execute batch OR'd with execbuf flags. If value is less
> + *  than 0, execute on all available rings.
> + * @dep_handle: handle to a buffer object dependency. If greater than 0, add 
> a
> + *  relocation entry to this buffer within the batch.
> + *
> + * Start a recursive batch on a ring. Immediately returns a #igt_spin_t that
> + * contains the batch's handle that can be waited upon. The returned 
> structure
> + * must be passed to igt_spin_batch_free() for post-processing.
> + *
> + * Returns:
> + * Structure with helper internal state for igt_spin_batch_free().
> + */
> +igt_spin_t *
> +igt_spin_batch_new(int fd, int engine, unsigned dep_handle)
> +{
> + igt_spin_t *spin = calloc(1, sizeof(struct igt_spin));
> + uint32_t handle = emit_recursive_batch(fd, engine, dep_handle);
> + igt_assert(gem_bo_busy(fd, handle));
> + at_exit_drm_fd = fd;
> + igt_install_exit_handler(quiescent_gpu_at_exit);

We already do igt_install_exit_handler(quiescent_gpu_at_exit); doing a
plain one ourselves still incurs a GPU hang if the user hits ^C. (And we
are installing one for every new spinner.)

What I meant was that if we kept a list of active spinners and walked
that list from gem_quiescent_gpu() we could leverage the existing
infrastructure to ensure that the GPU was idled as kick as possible
after a failed/interrupted test (without GPU hangs causing havoc).

P.S. imagine running checkpatch.pl and keeping in the habit of using the
kernel CodingStyle.
-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] ✗ Fi.CI.BAT: warning for series starting with [1/5] drm: Define drm_mm_for_each_node_in_range()

[Patchwork]

== Series Details ==

Series: series starting with [1/5] drm: Define drm_mm_for_each_node_in_range()
URL   : https://patchwork.freedesktop.org/series/15825/
State : warning

== Summary ==

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

Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-a:
pass   -> DMESG-WARN (fi-ilk-650)

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

01896e61d9cc0cad08e19990cd095cdf679f6142 drm-intel-nightly: 
2016y-11m-23d-14h-45m-53s UTC integration manifest
753bc0e drm/i915: Tidy i915_gem_valid_gtt_space()
f85a474 drm/i915: Fix i915_gem_evict_for_vma (soft-pinning)
9d2cdd7 drm/i915: Mark all non-vma being inserted into the address spaces
f81a48c drm: Check against color expansion in drm_mm_reserve_node()
46d7eb3 drm: Define drm_mm_for_each_node_in_range()

== Logs ==

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

Re: [Intel-gfx] [PATCH RFC] drm: Add a new connector atomic property for link status

[Daniel Vetter]

On Wed, Nov 23, 2016 at 4:52 PM, Jani Nikula
 wrote:
>> Take the CDN DP driver in rockchip for example (posted yesterday).
>> There's a worker in the driver that is responsible for handling
>> hpd/extcon events from the USB-C port. Ideally, this worker should
>> just be a thin shell around a kms uevent that lets userspace know
>> there's been a change. Unfortunately since we need to make re-training
>> work (/me grumbles about productization) seamlessly, we need to add a
>> bunch of goo into the worker to handle re-training. Since we need to
>> handle re-training there and in modeset, we need to properly
>> synchronize things. So we end up with a bunch of code that doesn't
>> *really* need to be there.
>>
>> So is the correct path forward to add GOOD/BAD connection handling to
>> Chrome/drm_hwc
>
> I think so.
>
>> and rip re-training out of the various kernel drivers?
>
> IMO if it works, don't change it, at least not in a rush. It also
> depends on the hardware and the driver; the amount of code required may
> be vastly different for various drivers.
>
> Personally, I think in the long run letting userspace help here leads to
> a simpler design and more efficient happy day scenario handling, and
> userspace knows what's going on.

We can't rip out re-training from existing drivers since it would
break existing userspace in certain cases (like cable re-plug into
same screen). But we could try to not implement so much for new
drivers.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH RFC] drm: Add a new connector atomic property for link status

[Sean Paul]

On Wed, Nov 23, 2016 at 10:52 AM, Jani Nikula
 wrote:
> On Wed, 23 Nov 2016, Sean Paul  wrote:
>> On Wed, Nov 23, 2016 at 10:15 AM, Jani Nikula
>>  wrote:
>>> On Wed, 23 Nov 2016, Sean Paul  wrote:
 On Wed, Nov 23, 2016 at 3:09 AM, Daniel Vetter  wrote:
> On Tue, Nov 22, 2016 at 09:27:35PM -0500, Sean Paul wrote:
>> On Tue, Nov 22, 2016 at 8:30 PM, Manasi Navare
>>  wrote:
>> > This is RFC patch for adding a connector link-status property
>> > and making it atomic by adding it to the drm_connector_state.
>> > This is to make sure its wired properly in 
>> > drm_atomic_connector_set_property
>> > and drm_atomic_connector_get_property functions.
>> >
>>
>> Thanks for sending this. We ran into some re-training awkwardness
>> recently, and I
>> was hoping for such a patch.
>>
>> > Cc: Jani Nikula 
>> > Cc: Daniel Vetter 
>> > Cc: Ville Syrjala 
>> > Cc: Chris Wilson 
>> > Signed-off-by: Manasi Navare 
>> > ---
>> >  drivers/gpu/drm/drm_atomic.c|  5 
>> >  drivers/gpu/drm/drm_connector.c | 65 
>> > +++--
>> >  include/drm/drm_connector.h | 12 +++-
>> >  include/drm/drm_mode_config.h   |  5 
>> >  include/uapi/drm/drm_mode.h |  4 +++
>> >  5 files changed, 88 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/drm_atomic.c 
>> > b/drivers/gpu/drm/drm_atomic.c
>> > index 89737e4..644d19f 100644
>> > --- a/drivers/gpu/drm/drm_atomic.c
>> > +++ b/drivers/gpu/drm/drm_atomic.c
>> > @@ -1087,6 +1087,9 @@ int drm_atomic_connector_set_property(struct 
>> > drm_connector *connector,
>> >  * now?) atomic writes to DPMS property:
>> >  */
>> > return -EINVAL;
>> > +   } else if (property == config->link_status_property) {
>> > +   state->link_status = val;
>
> I think we should have a check here to make sure userspace never tries to
> set this from "GOOD" to "BAD". "BAD" to "BAD" we need to allow, since with
> atomic userspace is supposed to be able to just restore everything to what
> it was.
>
> I don't think trying to set it to "BAD" should cause an error though, just
> silently keep the link status at "GOOG". So:
>
> /* Never downgrade from GOOD to BAD on userspace's request here,
>  * only hw issues can do that. */
> if (state->link_status == GOOD)
> return 0;

 Can we return an error if the transition is invalid?

> state->link_status = val;
> return 0;
>
>> > +   return 0;
>> > } else if (connector->funcs->atomic_set_property) {
>> > return connector->funcs->atomic_set_property(connector,
>> > state, property, val);
>> > @@ -1135,6 +1138,8 @@ static void 
>> > drm_atomic_connector_print_state(struct drm_printer *p,
>> > *val = (state->crtc) ? state->crtc->base.id : 0;
>> > } else if (property == config->dpms_property) {
>> > *val = connector->dpms;
>> > +   } else if (property == config->link_status_property) {
>> > +   *val = state->link_status;
>> > } else if (connector->funcs->atomic_get_property) {
>> > return connector->funcs->atomic_get_property(connector,
>> > state, property, val);
>> > diff --git a/drivers/gpu/drm/drm_connector.c 
>> > b/drivers/gpu/drm/drm_connector.c
>> > index 5a45262..4576c9f 100644
>> > --- a/drivers/gpu/drm/drm_connector.c
>> > +++ b/drivers/gpu/drm/drm_connector.c
>> > @@ -243,6 +243,10 @@ int drm_connector_init(struct drm_device *dev,
>> > drm_object_attach_property(>base,
>> >   config->dpms_property, 0);
>> >
>> > +   drm_object_attach_property(>base,
>> > +  config->link_status_property,
>> > +  0);
>> > +
>> > if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
>> > drm_object_attach_property(>base, 
>> > config->prop_crtc_id, 0);
>> > }
>> > @@ -506,6 +510,12 @@ const char *drm_get_subpixel_order_name(enum 
>> > subpixel_order order)
>> >  };
>> >  DRM_ENUM_NAME_FN(drm_get_dpms_name, drm_dpms_enum_list)
>> >
>> > +static const struct drm_prop_enum_list drm_link_status_enum_list[] = {
>> > +   { 

[Intel-gfx] [PATCH 0/5] HPD support during suspend for BXT/APL.

[Animesh Manna]

Along with below patches sharing some background details/design.
- On BXT, Display cannot generate an interrupt when in D3.
- Without display in D3, S0ix can be achieved, Power impact will be zero if d3 
is blocked. PMCSR for Graphics/Display is irrelevant, as the power management 
for them is taken care by the PUNIT using RC6/DC9 hints and *not* through PMCSR 
write trigger.

So solution is based on below principles:
- Display should not be put into D3 for HPD to work.
- With D0+DC9 we can achieve S0ix and at the same time helps to get the 
interrupt.
- Using pci_save_state() during suspend to take control from OSPM and blocking 
D3, while resuming, giving back to OSPM by pci_restore_state(). 
- _DSM method is used to program pmc hpd control register to enable hpd during 
suspend.

Please have a look and send your comments/suggestions.

v1: Initial version sent as RFC.

v2: Updated version after addressing review comments from Imre,David.

Animesh Manna (5):
  drm/i915/bxt: Corrected the guid for bxt.
  drm/i915/bxt: VBT changes for hpd as wakeup feature
  drm/i915/bxt: Added _DSM call to set HPD_CTL.
  drm/i915/bxt: Block D3 during suspend.
  drm/i915: Enable HPD interrupts with master ctl interrupt

 drivers/gpu/drm/i915/i915_drv.c   |  5 +++
 drivers/gpu/drm/i915/i915_drv.h   |  3 ++
 drivers/gpu/drm/i915/i915_irq.c   | 54 +--
 drivers/gpu/drm/i915/i915_reg.h   | 12 +++
 drivers/gpu/drm/i915/intel_acpi.c | 60 +++
 drivers/gpu/drm/i915/intel_bios.c |  6 
 drivers/gpu/drm/i915/intel_vbt_defs.h |  3 +-
 7 files changed, 132 insertions(+), 11 deletions(-)
 mode change 100644 => 100755 drivers/gpu/drm/i915/i915_irq.c
 mode change 100644 => 100755 drivers/gpu/drm/i915/intel_acpi.c

-- 
1.9.1

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

[Intel-gfx] [PATCH 3/5] drm/i915/bxt: Added _DSM call to set HPD_CTL.

[Animesh Manna]

_DSM is added to program HPD_CTL(0x1094) register
of PMC from i915 driver which will be called
based on driver feature flag. PMC hpd control register
programming will enable PMC to get hpd interrupt
during dc9.

Signed-off-by: Animesh Manna 
---
 drivers/gpu/drm/i915/intel_acpi.c | 44 ---
 1 file changed, 37 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_acpi.c 
b/drivers/gpu/drm/i915/intel_acpi.c
index 8c878ab..15d3b84 100755
--- a/drivers/gpu/drm/i915/intel_acpi.c
+++ b/drivers/gpu/drm/i915/intel_acpi.c
@@ -10,6 +10,8 @@
 
 #define INTEL_DSM_REVISION_ID 1 /* For Calpella anyway... */
 #define INTEL_DSM_FN_PLATFORM_MUX_INFO 1 /* No args */
+#define INTEL_DSM_SET_HPD_WAKEUP 17
+#define HPD_WAKEUP_EN_VAL 0xFCF0
 
 static struct intel_dsm_priv {
acpi_handle dhandle;
@@ -118,6 +120,25 @@ static void intel_dsm_platform_mux_info(void)
ACPI_FREE(pkg);
 }
 
+static void intel_dsm_set_hpd_wakeup(u8 *guid)
+{
+   union acpi_object *obj;
+   union acpi_object argv4 = {
+   .integer.type = ACPI_TYPE_INTEGER,
+   .integer.value = HPD_WAKEUP_EN_VAL,
+   };
+
+   obj = acpi_evaluate_dsm_typed(intel_dsm_priv.dhandle, guid,
+   INTEL_DSM_REVISION_ID, INTEL_DSM_SET_HPD_WAKEUP,
+   , ACPI_TYPE_INTEGER);
+
+   if (!obj)
+   DRM_DEBUG_DRIVER("failed to evaluate _DSM\n");
+
+   ACPI_FREE(obj);
+}
+
+
 static bool intel_dsm_pci_probe(struct pci_dev *pdev)
 {
acpi_handle dhandle;
@@ -134,14 +155,23 @@ static bool intel_dsm_pci_probe(struct pci_dev *pdev)
else
guid = intel_dsm_guid;
 
-   if (!acpi_check_dsm(dhandle, guid, INTEL_DSM_REVISION_ID,
-   1 << INTEL_DSM_FN_PLATFORM_MUX_INFO)) {
-   DRM_DEBUG_KMS("no _DSM method for intel device\n");
-   return false;
-   }
-
intel_dsm_priv.dhandle = dhandle;
-   intel_dsm_platform_mux_info();
+
+   if (acpi_check_dsm(dhandle, guid, INTEL_DSM_REVISION_ID,
+   1 << INTEL_DSM_FN_PLATFORM_MUX_INFO))
+   intel_dsm_platform_mux_info();
+   else
+   DRM_DEBUG_KMS("no _DSM method for mux-info\n");
+
+   /* Need to ensure vbt parsing is completed. */
+   if (dev_priv->vbt.hpd_wakeup_enabled &&
+   acpi_check_dsm(dhandle, guid, INTEL_DSM_REVISION_ID,
+   1 << INTEL_DSM_SET_HPD_WAKEUP))
+   intel_dsm_set_hpd_wakeup(guid);
+   else {
+   dev_priv->vbt.hpd_wakeup_enabled = false;
+   DRM_DEBUG_KMS("no _DSM method for hpd-enabling\n");
+   }
 
return true;
 }
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH RFC] drm: Add a new connector atomic property for link status

[Sean Paul]

On Wed, Nov 23, 2016 at 10:43 AM, Ville Syrjälä
 wrote:
> On Wed, Nov 23, 2016 at 10:32:44AM -0500, Sean Paul wrote:
>> On Wed, Nov 23, 2016 at 10:15 AM, Jani Nikula
>>  wrote:
>> > On Wed, 23 Nov 2016, Sean Paul  wrote:
>> >> On Wed, Nov 23, 2016 at 3:09 AM, Daniel Vetter  wrote:
>> >>> On Tue, Nov 22, 2016 at 09:27:35PM -0500, Sean Paul wrote:
>>  On Tue, Nov 22, 2016 at 8:30 PM, Manasi Navare
>>   wrote:
>>  > This is RFC patch for adding a connector link-status property
>>  > and making it atomic by adding it to the drm_connector_state.
>>  > This is to make sure its wired properly in 
>>  > drm_atomic_connector_set_property
>>  > and drm_atomic_connector_get_property functions.
>>  >
>> 
>>  Thanks for sending this. We ran into some re-training awkwardness
>>  recently, and I
>>  was hoping for such a patch.
>> 
>>  > Cc: Jani Nikula 
>>  > Cc: Daniel Vetter 
>>  > Cc: Ville Syrjala 
>>  > Cc: Chris Wilson 
>>  > Signed-off-by: Manasi Navare 
>>  > ---
>>  >  drivers/gpu/drm/drm_atomic.c|  5 
>>  >  drivers/gpu/drm/drm_connector.c | 65 
>>  > +++--
>>  >  include/drm/drm_connector.h | 12 +++-
>>  >  include/drm/drm_mode_config.h   |  5 
>>  >  include/uapi/drm/drm_mode.h |  4 +++
>>  >  5 files changed, 88 insertions(+), 3 deletions(-)
>>  >
>>  > diff --git a/drivers/gpu/drm/drm_atomic.c 
>>  > b/drivers/gpu/drm/drm_atomic.c
>>  > index 89737e4..644d19f 100644
>>  > --- a/drivers/gpu/drm/drm_atomic.c
>>  > +++ b/drivers/gpu/drm/drm_atomic.c
>>  > @@ -1087,6 +1087,9 @@ int drm_atomic_connector_set_property(struct 
>>  > drm_connector *connector,
>>  >  * now?) atomic writes to DPMS property:
>>  >  */
>>  > return -EINVAL;
>>  > +   } else if (property == config->link_status_property) {
>>  > +   state->link_status = val;
>> >>>
>> >>> I think we should have a check here to make sure userspace never tries to
>> >>> set this from "GOOD" to "BAD". "BAD" to "BAD" we need to allow, since 
>> >>> with
>> >>> atomic userspace is supposed to be able to just restore everything to 
>> >>> what
>> >>> it was.
>> >>>
>> >>> I don't think trying to set it to "BAD" should cause an error though, 
>> >>> just
>> >>> silently keep the link status at "GOOG". So:
>> >>>
>> >>> /* Never downgrade from GOOD to BAD on userspace's request here,
>> >>>  * only hw issues can do that. */
>> >>> if (state->link_status == GOOD)
>> >>> return 0;
>> >>
>> >> Can we return an error if the transition is invalid?
>> >>
>> >>> state->link_status = val;
>> >>> return 0;
>> >>>
>>  > +   return 0;
>>  > } else if (connector->funcs->atomic_set_property) {
>>  > return 
>>  > connector->funcs->atomic_set_property(connector,
>>  > state, property, val);
>>  > @@ -1135,6 +1138,8 @@ static void 
>>  > drm_atomic_connector_print_state(struct drm_printer *p,
>>  > *val = (state->crtc) ? state->crtc->base.id : 0;
>>  > } else if (property == config->dpms_property) {
>>  > *val = connector->dpms;
>>  > +   } else if (property == config->link_status_property) {
>>  > +   *val = state->link_status;
>>  > } else if (connector->funcs->atomic_get_property) {
>>  > return 
>>  > connector->funcs->atomic_get_property(connector,
>>  > state, property, val);
>>  > diff --git a/drivers/gpu/drm/drm_connector.c 
>>  > b/drivers/gpu/drm/drm_connector.c
>>  > index 5a45262..4576c9f 100644
>>  > --- a/drivers/gpu/drm/drm_connector.c
>>  > +++ b/drivers/gpu/drm/drm_connector.c
>>  > @@ -243,6 +243,10 @@ int drm_connector_init(struct drm_device *dev,
>>  > drm_object_attach_property(>base,
>>  >   config->dpms_property, 0);
>>  >
>>  > +   drm_object_attach_property(>base,
>>  > +  config->link_status_property,
>>  > +  0);
>>  > +
>>  > if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
>>  > drm_object_attach_property(>base, 
>>  > config->prop_crtc_id, 0);
>>  > }
>>  > @@ -506,6 +510,12 @@ const char *drm_get_subpixel_order_name(enum 
>>  > subpixel_order order)
>>  >  };
>>  >  

[Intel-gfx] [PATCH 4/5] drm/i915/bxt: Block D3 during suspend.

[Animesh Manna]

For BXT, display engine can not generate interrupt when in D3.
On the othen hand S0ix can be achieved without display in D3. So,
Display should not put into D3 for HPD to work and will not
have any power impact.

v1: Initial version as RFC.

v2: Based on review comment from David,
condition check for hpd_wakeup_enabled is removed before
calling pci_restore_state.

Signed-off-by: Animesh Manna 
---
 drivers/gpu/drm/i915/i915_drv.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 4f0e56d..bc48642 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -2381,6 +2381,9 @@ static int intel_runtime_suspend(struct device *kdev)
if (!IS_VALLEYVIEW(dev_priv) || !IS_CHERRYVIEW(dev_priv))
intel_hpd_poll_init(dev_priv);
 
+   if (dev_priv->vbt.hpd_wakeup_enabled)
+   pci_save_state(pdev);
+
DRM_DEBUG_KMS("Device suspended\n");
return 0;
 }
@@ -2397,6 +2400,8 @@ static int intel_runtime_resume(struct device *kdev)
 
DRM_DEBUG_KMS("Resuming device\n");
 
+   pci_restore_state(pdev);
+
WARN_ON_ONCE(atomic_read(_priv->pm.wakeref_count));
disable_rpm_wakeref_asserts(dev_priv);
 
-- 
1.9.1

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

[Intel-gfx] [PATCH 5/5] drm/i915: Enable HPD interrupts with master ctl interrupt

[Animesh Manna]

While suspending the device hpd related interrupts are enabled
to get the interrupt when device is in suspend state.

Though display is in DC9 but system can be in S0 or S0i3 state.
Hot plug during S0 state will generate de_port_interrupt but if
system is in S0i3 state then display driver will get hotplug
interrupt as pcu_hpd_interrupt which will come via pmc. So
added the interrupt handling for pcu hpd interrupt.

Signed-off-by: Animesh Manna 
Signed-off-by: A.Sunil Kamath 
---
 drivers/gpu/drm/i915/i915_irq.c | 56 ++---
 drivers/gpu/drm/i915/i915_reg.h | 12 +
 2 files changed, 65 insertions(+), 3 deletions(-)
 mode change 100644 => 100755 drivers/gpu/drm/i915/i915_irq.c

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
old mode 100644
new mode 100755
index cb8a75f..2f9b604
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -110,9 +110,9 @@
 
 /* BXT hpd list */
 static const u32 hpd_bxt[HPD_NUM_PINS] = {
-   [HPD_PORT_A] = BXT_DE_PORT_HP_DDIA,
-   [HPD_PORT_B] = BXT_DE_PORT_HP_DDIB,
-   [HPD_PORT_C] = BXT_DE_PORT_HP_DDIC
+   [HPD_PORT_A] = (BXT_DE_PORT_HP_DDIA | BXT_PCU_DC9_HP_DDIA),
+   [HPD_PORT_B] = (BXT_DE_PORT_HP_DDIB | BXT_PCU_DC9_HP_DDIB),
+   [HPD_PORT_C] = (BXT_DE_PORT_HP_DDIC | BXT_PCU_DC9_HP_DDIC)
 };
 
 /* IIR can theoretically queue up two events. Be paranoid. */
@@ -2463,6 +2463,24 @@ static void bxt_hpd_irq_handler(struct drm_i915_private 
*dev_priv,
DRM_ERROR("The master control interrupt lied (DE 
PORT)!\n");
}
 
+   if (master_ctl & GEN8_PCU_IRQ) {
+   iir = I915_READ(GEN8_PCU_IIR);
+   if (iir) {
+   u32 tmp_mask;
+
+   I915_WRITE(GEN8_PCU_IIR, iir);
+   ret = IRQ_HANDLED;
+   if (IS_BROXTON(dev_priv)) {
+   tmp_mask = iir & BXT_PCU_DC9_HOTPLUG_MASK;
+   if (tmp_mask)
+   bxt_hpd_irq_handler(dev_priv, tmp_mask,
+   hpd_bxt);
+   } else
+   DRM_ERROR("Unexpected PCU interrupt\n");
+   } else
+   DRM_ERROR("The master control interrupt lied (PCU)!\n");
+   }
+
for_each_pipe(dev_priv, pipe) {
u32 flip_done, fault_errors;
 
@@ -4294,6 +4312,19 @@ void intel_irq_uninstall(struct drm_i915_private 
*dev_priv)
dev_priv->pm.irqs_enabled = false;
 }
 
+static void bxt_enable_pcu_interrupt(struct drm_i915_private *dev_priv)
+{
+   u32 de_pcu_hpd_enable_mask, de_pcu_imr, de_pcu_ier;
+
+   de_pcu_hpd_enable_mask = GEN9_DE_PCU_PORTA_HOTPLUG |
+   GEN9_DE_PCU_PORTB_HOTPLUG |
+   GEN9_DE_PCU_PORTC_HOTPLUG;
+
+   de_pcu_imr = (I915_READ(GEN8_PCU_IMR) & 0x0);
+   de_pcu_ier = (I915_READ(GEN8_PCU_IER) | de_pcu_hpd_enable_mask);
+   GEN5_IRQ_INIT(GEN8_PCU_, de_pcu_imr, de_pcu_ier);
+}
+
 /**
  * intel_runtime_pm_disable_interrupts - runtime interrupt disabling
  * @dev_priv: i915 device instance
@@ -4303,8 +4334,27 @@ void intel_irq_uninstall(struct drm_i915_private 
*dev_priv)
  */
 void intel_runtime_pm_disable_interrupts(struct drm_i915_private *dev_priv)
 {
+   unsigned long flags = 0;
+
dev_priv->drm.driver->irq_uninstall(_priv->drm);
dev_priv->pm.irqs_enabled = false;
+
+   if (IS_BROXTON(dev_priv) && dev_priv->vbt.hpd_wakeup_enabled) {
+
+   /* Enable HPD related interrupts during DC9 for HPD wakeup */
+
+   I915_WRITE(GEN8_MASTER_IRQ, GEN8_MASTER_IRQ_CONTROL);
+   POSTING_READ(GEN8_MASTER_IRQ);
+
+   spin_lock_irqsave(_priv->irq_lock, flags);
+   if (dev_priv->display.hpd_irq_setup)
+   dev_priv->display.hpd_irq_setup(dev_priv);
+   spin_unlock_irqrestore(_priv->irq_lock, flags);
+
+   bxt_enable_pcu_interrupt(dev_priv);
+
+   dev_priv->pm.irqs_enabled = true;
+   }
synchronize_irq(dev_priv->drm.irq);
 }
 
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 3361d7f..df89025 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6030,6 +6030,18 @@ enum {
 #define GEN8_PCU_IIR _MMIO(0x444e8)
 #define GEN8_PCU_IER _MMIO(0x444ec)
 
+/* BXT PCU DC9 hotplug control */
+#define BXT_PCU_DC9_HP_DDIA(1<<31)
+#define BXT_PCU_DC9_HP_DDIB(1<<30)
+#define BXT_PCU_DC9_HP_DDIC(1<<29)
+#define BXT_PCU_DC9_HOTPLUG_MASK   (BXT_PCU_DC9_HP_DDIA | \
+BXT_PCU_DC9_HP_DDIB | \
+BXT_PCU_DC9_HP_DDIC)
+
+#define GEN9_DE_PCU_PORTA_HOTPLUG  (1 << 31)

[Intel-gfx] [PATCH 1/5] drm/i915/bxt: Corrected the guid for bxt.

[Animesh Manna]

Guid is changed for bxt platform, so corrected the guid for bxt.

v1: Initial version as RFC.

v2: Based on review comment from Jani and David,
have kept guid as binary format.

Signed-off-by: Ananth Krishna R 
Signed-off-by: Bharath K Veera 
Signed-off-by: Animesh Manna 
---
 drivers/gpu/drm/i915/intel_acpi.c | 20 ++--
 1 file changed, 18 insertions(+), 2 deletions(-)
 mode change 100644 => 100755 drivers/gpu/drm/i915/intel_acpi.c

diff --git a/drivers/gpu/drm/i915/intel_acpi.c 
b/drivers/gpu/drm/i915/intel_acpi.c
old mode 100644
new mode 100755
index eb638a1..8c878ab
--- a/drivers/gpu/drm/i915/intel_acpi.c
+++ b/drivers/gpu/drm/i915/intel_acpi.c
@@ -15,7 +15,7 @@
acpi_handle dhandle;
 } intel_dsm_priv;
 
-static const u8 intel_dsm_guid[] = {
+static u8 intel_dsm_guid[] = {
0xd3, 0x73, 0xd8, 0x7e,
0xd0, 0xc2,
0x4f, 0x4e,
@@ -23,6 +23,14 @@
0x0f, 0x13, 0x17, 0xb0, 0x1c, 0x2c
 };
 
+static u8 intel_dsm_guid_bxt[] = {
+   0xc6, 0x41, 0x5b, 0x3e,
+   0x1d, 0xeb,
+   0x60, 0x42,
+   0x9d, 0x15,
+   0xc7, 0x1f, 0xba, 0xda, 0xe4, 0x14
+};
+
 static char *intel_dsm_port_name(u8 id)
 {
switch (id) {
@@ -113,12 +121,20 @@ static void intel_dsm_platform_mux_info(void)
 static bool intel_dsm_pci_probe(struct pci_dev *pdev)
 {
acpi_handle dhandle;
+   struct drm_device *dev = pci_get_drvdata(pdev);
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   u8 *guid;
 
dhandle = ACPI_HANDLE(>dev);
if (!dhandle)
return false;
 
-   if (!acpi_check_dsm(dhandle, intel_dsm_guid, INTEL_DSM_REVISION_ID,
+   if (IS_BROXTON(dev_priv))
+   guid = intel_dsm_guid_bxt;
+   else
+   guid = intel_dsm_guid;
+
+   if (!acpi_check_dsm(dhandle, guid, INTEL_DSM_REVISION_ID,
1 << INTEL_DSM_FN_PLATFORM_MUX_INFO)) {
DRM_DEBUG_KMS("no _DSM method for intel device\n");
return false;
-- 
1.9.1

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

[Intel-gfx] [PATCH 2/5] drm/i915/bxt: VBT changes for hpd as wakeup feature

[Animesh Manna]

To support hpd during sleep a new feature flag is
added in vbt and also in dev_priv for enabling/disabling
inside driver. By default this feature will be
disabled and based on oem request this feature can
be enabled by changing vbt feature flag.

v1: Initial version as RFC.

v2: Based on review comments from Jani,
- Used bool instead of enum for hpd feature flag.
- Updating feature flag at the first place based on vbt
entry.

Signed-off-by: Animesh Manna 
Signed-off-by: A.Sunil Kamath 
---
 drivers/gpu/drm/i915/i915_drv.h   | 3 +++
 drivers/gpu/drm/i915/intel_bios.c | 6 ++
 drivers/gpu/drm/i915/intel_vbt_defs.h | 3 ++-
 3 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4e7148a..1c3cf31 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1583,6 +1583,9 @@ struct intel_vbt_data {
const u8 *sequence[MIPI_SEQ_MAX];
} dsi;
 
+   /* HPD as wakesoure for DC9 BXT */
+   bool hpd_wakeup_enabled;
+
int crt_ddc_pin;
 
int child_dev_num;
diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index 7ffab1a..da4a7fd 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -557,6 +557,12 @@ static int intel_bios_ssc_frequency(struct 
drm_i915_private *dev_priv,
if (driver->lvds_config == BDB_DRIVER_FEATURE_EDP)
dev_priv->vbt.edp.support = 1;
 
+   if (driver->hpd_wakeup_source) {
+   dev_priv->vbt.hpd_wakeup_enabled = true;
+   DRM_DEBUG_KMS("HPD as wakeup feature is enabled\n");
+   } else
+   DRM_DEBUG_KMS("HPD wakeup source feature is disabled in VBT\n");
+
DRM_DEBUG_KMS("DRRS State Enabled:%d\n", driver->drrs_enabled);
/*
 * If DRRS is not supported, drrs_type has to be set to 0.
diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h 
b/drivers/gpu/drm/i915/intel_vbt_defs.h
index 8886cab1..2072134 100644
--- a/drivers/gpu/drm/i915/intel_vbt_defs.h
+++ b/drivers/gpu/drm/i915/intel_vbt_defs.h
@@ -561,7 +561,8 @@ struct bdb_driver_features {
u16 tbt_enabled:1;
u16 psr_enabled:1;
u16 ips_enabled:1;
-   u16 reserved3:4;
+   u16 reserved3:3;
+   u16 hpd_wakeup_source:1;
u16 pc_feature_valid:1;
 } __packed;
 
-- 
1.9.1

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

[Intel-gfx] [i-g-t PATCH v11 2/5] lib: add igt_dummyload

[Abdiel Janulgue]

A lot of igt testcases need some GPU workload to make sure a race
window is big enough. Unfortunately having a fixed amount of
workload leads to spurious test failures or overly long runtimes
on some fast/slow platforms. This library contains functionality
to submit GPU workloads that should consume exactly a specific
amount of time.

v2 : Add recursive batch feature from Chris
v3 : Drop auto-tuned stuff. Add bo dependecy to recursive batch
 by adding a dummy reloc to the bo as suggested by Ville.
v4:  Fix dependency reloc as write instead of read (Ville).
 Fix wrong handling of batchbuffer start on ILK causing
 test failure
v5:  Convert kms_busy to use this api
v6:  Add this library to docs
v7:  Document global use of batch, reuse defines
 Minor code cleanups.
 Rename igt_spin_batch and igt_post_spin_batch to
 igt_spin_batch_new and igt_spin_batch_free
 respectively (Tomeu Vizoso).
 Fix error in dependency relocation handling in HSW causing
 tests to fail.
v8:  Restore correct order of objects in the execbuffer. Batch
 object should always be last.
v9 : Add helper to terminate batch manually
v10: Split timeout function. Clarify function names (Chris)
v11: From Chris:
 * Add gem_quiescent_gpu exit handler
 * Use gem_bo_busy
 * Skip spin->handle > 0 checks
 * Ensure terminate batch on free
 * Remove igt_spin_batch_wait
 * Remove single-ring limitation

Cc: Daniel Vetter 
Cc: Ville Syrjälä 
Cc: Chris Wilson 
Cc: to...@tomeuvizoso.net
Reviewed-by: Tomeu Vizoso 
Signed-off-by: Abdiel Janulgue 
---
 .../intel-gpu-tools/intel-gpu-tools-docs.xml   |   1 +
 lib/Makefile.sources   |   2 +
 lib/igt.h  |   1 +
 lib/igt_dummyload.c| 283 +
 lib/igt_dummyload.h|  44 
 5 files changed, 331 insertions(+)
 create mode 100644 lib/igt_dummyload.c
 create mode 100644 lib/igt_dummyload.h

diff --git a/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml 
b/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml
index c862f2a..55902ab 100644
--- a/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml
+++ b/docs/reference/intel-gpu-tools/intel-gpu-tools-docs.xml
@@ -32,6 +32,7 @@
 
 
 
+
   
   
 
diff --git a/lib/Makefile.sources b/lib/Makefile.sources
index e8e277b..7fc5ec2 100644
--- a/lib/Makefile.sources
+++ b/lib/Makefile.sources
@@ -75,6 +75,8 @@ lib_source_list = \
igt_draw.h  \
igt_pm.c\
igt_pm.h\
+   igt_dummyload.c \
+   igt_dummyload.h \
uwildmat/uwildmat.h \
uwildmat/uwildmat.c \
$(NULL)
diff --git a/lib/igt.h b/lib/igt.h
index d751f24..a0028d5 100644
--- a/lib/igt.h
+++ b/lib/igt.h
@@ -32,6 +32,7 @@
 #include "igt_core.h"
 #include "igt_debugfs.h"
 #include "igt_draw.h"
+#include "igt_dummyload.h"
 #include "igt_fb.h"
 #include "igt_gt.h"
 #include "igt_kms.h"
diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c
new file mode 100644
index 000..7068bcb
--- /dev/null
+++ b/lib/igt_dummyload.c
@@ -0,0 +1,283 @@
+/*
+ * 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
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include "igt.h"
+#include "igt_dummyload.h"
+#include 
+#include 
+#include 
+
+/**
+ * SECTION:igt_dummyload
+ * @short_description: Library for submitting GPU workloads
+ * @title: Dummyload
+ * @include: igt.h
+ *
+ * A lot of igt testcases need some GPU workload to make sure a race window is
+ * big enough. Unfortunately having a fixed amount of workload leads to
+ * spurious test failures or overly long runtimes on some 

Re: [Intel-gfx] [PATCH RFC] drm: Add a new connector atomic property for link status

[Jani Nikula]

On Wed, 23 Nov 2016, Sean Paul  wrote:
> On Wed, Nov 23, 2016 at 10:15 AM, Jani Nikula
>  wrote:
>> On Wed, 23 Nov 2016, Sean Paul  wrote:
>>> On Wed, Nov 23, 2016 at 3:09 AM, Daniel Vetter  wrote:
 On Tue, Nov 22, 2016 at 09:27:35PM -0500, Sean Paul wrote:
> On Tue, Nov 22, 2016 at 8:30 PM, Manasi Navare
>  wrote:
> > This is RFC patch for adding a connector link-status property
> > and making it atomic by adding it to the drm_connector_state.
> > This is to make sure its wired properly in 
> > drm_atomic_connector_set_property
> > and drm_atomic_connector_get_property functions.
> >
>
> Thanks for sending this. We ran into some re-training awkwardness
> recently, and I
> was hoping for such a patch.
>
> > Cc: Jani Nikula 
> > Cc: Daniel Vetter 
> > Cc: Ville Syrjala 
> > Cc: Chris Wilson 
> > Signed-off-by: Manasi Navare 
> > ---
> >  drivers/gpu/drm/drm_atomic.c|  5 
> >  drivers/gpu/drm/drm_connector.c | 65 
> > +++--
> >  include/drm/drm_connector.h | 12 +++-
> >  include/drm/drm_mode_config.h   |  5 
> >  include/uapi/drm/drm_mode.h |  4 +++
> >  5 files changed, 88 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 89737e4..644d19f 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -1087,6 +1087,9 @@ int drm_atomic_connector_set_property(struct 
> > drm_connector *connector,
> >  * now?) atomic writes to DPMS property:
> >  */
> > return -EINVAL;
> > +   } else if (property == config->link_status_property) {
> > +   state->link_status = val;

 I think we should have a check here to make sure userspace never tries to
 set this from "GOOD" to "BAD". "BAD" to "BAD" we need to allow, since with
 atomic userspace is supposed to be able to just restore everything to what
 it was.

 I don't think trying to set it to "BAD" should cause an error though, just
 silently keep the link status at "GOOG". So:

 /* Never downgrade from GOOD to BAD on userspace's request here,
  * only hw issues can do that. */
 if (state->link_status == GOOD)
 return 0;
>>>
>>> Can we return an error if the transition is invalid?
>>>
 state->link_status = val;
 return 0;

> > +   return 0;
> > } else if (connector->funcs->atomic_set_property) {
> > return connector->funcs->atomic_set_property(connector,
> > state, property, val);
> > @@ -1135,6 +1138,8 @@ static void 
> > drm_atomic_connector_print_state(struct drm_printer *p,
> > *val = (state->crtc) ? state->crtc->base.id : 0;
> > } else if (property == config->dpms_property) {
> > *val = connector->dpms;
> > +   } else if (property == config->link_status_property) {
> > +   *val = state->link_status;
> > } else if (connector->funcs->atomic_get_property) {
> > return connector->funcs->atomic_get_property(connector,
> > state, property, val);
> > diff --git a/drivers/gpu/drm/drm_connector.c 
> > b/drivers/gpu/drm/drm_connector.c
> > index 5a45262..4576c9f 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -243,6 +243,10 @@ int drm_connector_init(struct drm_device *dev,
> > drm_object_attach_property(>base,
> >   config->dpms_property, 0);
> >
> > +   drm_object_attach_property(>base,
> > +  config->link_status_property,
> > +  0);
> > +
> > if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
> > drm_object_attach_property(>base, 
> > config->prop_crtc_id, 0);
> > }
> > @@ -506,6 +510,12 @@ const char *drm_get_subpixel_order_name(enum 
> > subpixel_order order)
> >  };
> >  DRM_ENUM_NAME_FN(drm_get_dpms_name, drm_dpms_enum_list)
> >
> > +static const struct drm_prop_enum_list drm_link_status_enum_list[] = {
> > +   { DRM_MODE_LINK_STATUS_GOOD, "Good" },
> > +   { DRM_MODE_LINK_STATUS_BAD, "Bad" },
> > +};
> > +DRM_ENUM_NAME_FN(drm_get_link_status_name, drm_link_status_enum_list)
> > +
> >  

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm: Hold mode_config.lock to prevent hotplug whilst setting up crtcs

[Patchwork]

== Series Details ==

Series: series starting with [1/3] drm: Hold mode_config.lock to prevent 
hotplug whilst setting up crtcs
URL   : https://patchwork.freedesktop.org/series/15823/
State : success

== Summary ==

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


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

01896e61d9cc0cad08e19990cd095cdf679f6142 drm-intel-nightly: 
2016y-11m-23d-14h-45m-53s UTC integration manifest
82c26ed drm: Protect fb_helper list manipulation with a mutex
7b135e9 drm: Pull together probe + setup for drm_fb_helper
8f48c48 drm: Hold mode_config.lock to prevent hotplug whilst setting up crtcs

== Logs ==

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

Re: [Intel-gfx] [PATCH RFC] drm: Add a new connector atomic property for link status

[Ville Syrjälä]

On Wed, Nov 23, 2016 at 10:32:44AM -0500, Sean Paul wrote:
> On Wed, Nov 23, 2016 at 10:15 AM, Jani Nikula
>  wrote:
> > On Wed, 23 Nov 2016, Sean Paul  wrote:
> >> On Wed, Nov 23, 2016 at 3:09 AM, Daniel Vetter  wrote:
> >>> On Tue, Nov 22, 2016 at 09:27:35PM -0500, Sean Paul wrote:
>  On Tue, Nov 22, 2016 at 8:30 PM, Manasi Navare
>   wrote:
>  > This is RFC patch for adding a connector link-status property
>  > and making it atomic by adding it to the drm_connector_state.
>  > This is to make sure its wired properly in 
>  > drm_atomic_connector_set_property
>  > and drm_atomic_connector_get_property functions.
>  >
> 
>  Thanks for sending this. We ran into some re-training awkwardness
>  recently, and I
>  was hoping for such a patch.
> 
>  > Cc: Jani Nikula 
>  > Cc: Daniel Vetter 
>  > Cc: Ville Syrjala 
>  > Cc: Chris Wilson 
>  > Signed-off-by: Manasi Navare 
>  > ---
>  >  drivers/gpu/drm/drm_atomic.c|  5 
>  >  drivers/gpu/drm/drm_connector.c | 65 
>  > +++--
>  >  include/drm/drm_connector.h | 12 +++-
>  >  include/drm/drm_mode_config.h   |  5 
>  >  include/uapi/drm/drm_mode.h |  4 +++
>  >  5 files changed, 88 insertions(+), 3 deletions(-)
>  >
>  > diff --git a/drivers/gpu/drm/drm_atomic.c 
>  > b/drivers/gpu/drm/drm_atomic.c
>  > index 89737e4..644d19f 100644
>  > --- a/drivers/gpu/drm/drm_atomic.c
>  > +++ b/drivers/gpu/drm/drm_atomic.c
>  > @@ -1087,6 +1087,9 @@ int drm_atomic_connector_set_property(struct 
>  > drm_connector *connector,
>  >  * now?) atomic writes to DPMS property:
>  >  */
>  > return -EINVAL;
>  > +   } else if (property == config->link_status_property) {
>  > +   state->link_status = val;
> >>>
> >>> I think we should have a check here to make sure userspace never tries to
> >>> set this from "GOOD" to "BAD". "BAD" to "BAD" we need to allow, since with
> >>> atomic userspace is supposed to be able to just restore everything to what
> >>> it was.
> >>>
> >>> I don't think trying to set it to "BAD" should cause an error though, just
> >>> silently keep the link status at "GOOG". So:
> >>>
> >>> /* Never downgrade from GOOD to BAD on userspace's request here,
> >>>  * only hw issues can do that. */
> >>> if (state->link_status == GOOD)
> >>> return 0;
> >>
> >> Can we return an error if the transition is invalid?
> >>
> >>> state->link_status = val;
> >>> return 0;
> >>>
>  > +   return 0;
>  > } else if (connector->funcs->atomic_set_property) {
>  > return connector->funcs->atomic_set_property(connector,
>  > state, property, val);
>  > @@ -1135,6 +1138,8 @@ static void 
>  > drm_atomic_connector_print_state(struct drm_printer *p,
>  > *val = (state->crtc) ? state->crtc->base.id : 0;
>  > } else if (property == config->dpms_property) {
>  > *val = connector->dpms;
>  > +   } else if (property == config->link_status_property) {
>  > +   *val = state->link_status;
>  > } else if (connector->funcs->atomic_get_property) {
>  > return connector->funcs->atomic_get_property(connector,
>  > state, property, val);
>  > diff --git a/drivers/gpu/drm/drm_connector.c 
>  > b/drivers/gpu/drm/drm_connector.c
>  > index 5a45262..4576c9f 100644
>  > --- a/drivers/gpu/drm/drm_connector.c
>  > +++ b/drivers/gpu/drm/drm_connector.c
>  > @@ -243,6 +243,10 @@ int drm_connector_init(struct drm_device *dev,
>  > drm_object_attach_property(>base,
>  >   config->dpms_property, 0);
>  >
>  > +   drm_object_attach_property(>base,
>  > +  config->link_status_property,
>  > +  0);
>  > +
>  > if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
>  > drm_object_attach_property(>base, 
>  > config->prop_crtc_id, 0);
>  > }
>  > @@ -506,6 +510,12 @@ const char *drm_get_subpixel_order_name(enum 
>  > subpixel_order order)
>  >  };
>  >  DRM_ENUM_NAME_FN(drm_get_dpms_name, drm_dpms_enum_list)
>  >
>  > +static const struct drm_prop_enum_list drm_link_status_enum_list[] = {
>  > +   { DRM_MODE_LINK_STATUS_GOOD, "Good" },
>  > +   { DRM_MODE_LINK_STATUS_BAD, "Bad" },
> 

Re: [Intel-gfx] [PATCH RFC] drm: Add a new connector atomic property for link status

[Sean Paul]

On Wed, Nov 23, 2016 at 10:15 AM, Jani Nikula
 wrote:
> On Wed, 23 Nov 2016, Sean Paul  wrote:
>> On Wed, Nov 23, 2016 at 3:09 AM, Daniel Vetter  wrote:
>>> On Tue, Nov 22, 2016 at 09:27:35PM -0500, Sean Paul wrote:
 On Tue, Nov 22, 2016 at 8:30 PM, Manasi Navare
  wrote:
 > This is RFC patch for adding a connector link-status property
 > and making it atomic by adding it to the drm_connector_state.
 > This is to make sure its wired properly in 
 > drm_atomic_connector_set_property
 > and drm_atomic_connector_get_property functions.
 >

 Thanks for sending this. We ran into some re-training awkwardness
 recently, and I
 was hoping for such a patch.

 > Cc: Jani Nikula 
 > Cc: Daniel Vetter 
 > Cc: Ville Syrjala 
 > Cc: Chris Wilson 
 > Signed-off-by: Manasi Navare 
 > ---
 >  drivers/gpu/drm/drm_atomic.c|  5 
 >  drivers/gpu/drm/drm_connector.c | 65 
 > +++--
 >  include/drm/drm_connector.h | 12 +++-
 >  include/drm/drm_mode_config.h   |  5 
 >  include/uapi/drm/drm_mode.h |  4 +++
 >  5 files changed, 88 insertions(+), 3 deletions(-)
 >
 > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
 > index 89737e4..644d19f 100644
 > --- a/drivers/gpu/drm/drm_atomic.c
 > +++ b/drivers/gpu/drm/drm_atomic.c
 > @@ -1087,6 +1087,9 @@ int drm_atomic_connector_set_property(struct 
 > drm_connector *connector,
 >  * now?) atomic writes to DPMS property:
 >  */
 > return -EINVAL;
 > +   } else if (property == config->link_status_property) {
 > +   state->link_status = val;
>>>
>>> I think we should have a check here to make sure userspace never tries to
>>> set this from "GOOD" to "BAD". "BAD" to "BAD" we need to allow, since with
>>> atomic userspace is supposed to be able to just restore everything to what
>>> it was.
>>>
>>> I don't think trying to set it to "BAD" should cause an error though, just
>>> silently keep the link status at "GOOG". So:
>>>
>>> /* Never downgrade from GOOD to BAD on userspace's request here,
>>>  * only hw issues can do that. */
>>> if (state->link_status == GOOD)
>>> return 0;
>>
>> Can we return an error if the transition is invalid?
>>
>>> state->link_status = val;
>>> return 0;
>>>
 > +   return 0;
 > } else if (connector->funcs->atomic_set_property) {
 > return connector->funcs->atomic_set_property(connector,
 > state, property, val);
 > @@ -1135,6 +1138,8 @@ static void 
 > drm_atomic_connector_print_state(struct drm_printer *p,
 > *val = (state->crtc) ? state->crtc->base.id : 0;
 > } else if (property == config->dpms_property) {
 > *val = connector->dpms;
 > +   } else if (property == config->link_status_property) {
 > +   *val = state->link_status;
 > } else if (connector->funcs->atomic_get_property) {
 > return connector->funcs->atomic_get_property(connector,
 > state, property, val);
 > diff --git a/drivers/gpu/drm/drm_connector.c 
 > b/drivers/gpu/drm/drm_connector.c
 > index 5a45262..4576c9f 100644
 > --- a/drivers/gpu/drm/drm_connector.c
 > +++ b/drivers/gpu/drm/drm_connector.c
 > @@ -243,6 +243,10 @@ int drm_connector_init(struct drm_device *dev,
 > drm_object_attach_property(>base,
 >   config->dpms_property, 0);
 >
 > +   drm_object_attach_property(>base,
 > +  config->link_status_property,
 > +  0);
 > +
 > if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
 > drm_object_attach_property(>base, 
 > config->prop_crtc_id, 0);
 > }
 > @@ -506,6 +510,12 @@ const char *drm_get_subpixel_order_name(enum 
 > subpixel_order order)
 >  };
 >  DRM_ENUM_NAME_FN(drm_get_dpms_name, drm_dpms_enum_list)
 >
 > +static const struct drm_prop_enum_list drm_link_status_enum_list[] = {
 > +   { DRM_MODE_LINK_STATUS_GOOD, "Good" },
 > +   { DRM_MODE_LINK_STATUS_BAD, "Bad" },
 > +};
 > +DRM_ENUM_NAME_FN(drm_get_link_status_name, drm_link_status_enum_list)
 > +
 >  /**
 >   * drm_display_info_set_bus_formats - set the supported bus formats
 >   * @info: display info to store bus formats in
 > @@ -616,7 +626,7 @@ int 

Re: [Intel-gfx] [PATCH v2] drm/i915: Remove all ->config dereferences from intel_hdmi, v2.

[Ville Syrjälä]

On Wed, Nov 23, 2016 at 03:57:00PM +0100, Maarten Lankhorst wrote:
> In all cases we can now obtain the relevant crtc_state/conn_state
> from the relevant callbacks, which means all the ->config accesses
> can be removed and the code cleaned up.
> 
> Changes since v1:
> - cstate -> crtc_state
> 
> Signed-off-by: Maarten Lankhorst 
> ---

> @@ -560,28 +566,16 @@ static void g4x_set_infoframes(struct drm_encoder 
> *encoder,
>   I915_WRITE(reg, val);
>   POSTING_READ(reg);
>  
> - intel_hdmi_set_avi_infoframe(encoder, adjusted_mode);
> - intel_hdmi_set_spd_infoframe(encoder);
> - intel_hdmi_set_hdmi_infoframe(encoder, adjusted_mode);
> + intel_hdmi_set_avi_infoframe(encoder, crtc_state);
> + intel_hdmi_set_spd_infoframe(encoder, crtc_state);
> + intel_hdmi_set_hdmi_infoframe(encoder, crtc_state);
>  }
>  
> -static bool hdmi_sink_is_deep_color(struct drm_encoder *encoder)
> +static bool hdmi_sink_is_deep_color(const struct drm_connector_state 
> *conn_state)
>  {
> - struct drm_device *dev = encoder->dev;
> - struct drm_connector *connector;
> -
> - WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
> + struct drm_connector *connector = conn_state->connector;
>  
> - /*
> -  * HDMI cloning is only supported on g4x which doesn't
> -  * support deep color or GCP infoframes anyway so no
> -  * need to worry about multiple HDMI sinks here.
> -  */

Please don't remove that comment.

With the comment restored this is
Reviewed-by: Ville Syrjälä 

> - list_for_each_entry(connector, >mode_config.connector_list, head)
> - if (connector->encoder == encoder)
> - return connector->display_info.bpc > 8;
> -
> - return false;
> + return connector->display_info.bpc > 8;
>  }
>  
>  /*
  

-- 
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 RFC] drm: Add a new connector atomic property for link status

[Jani Nikula]

On Wed, 23 Nov 2016, Sean Paul  wrote:
> On Wed, Nov 23, 2016 at 3:09 AM, Daniel Vetter  wrote:
>> On Tue, Nov 22, 2016 at 09:27:35PM -0500, Sean Paul wrote:
>>> On Tue, Nov 22, 2016 at 8:30 PM, Manasi Navare
>>>  wrote:
>>> > This is RFC patch for adding a connector link-status property
>>> > and making it atomic by adding it to the drm_connector_state.
>>> > This is to make sure its wired properly in 
>>> > drm_atomic_connector_set_property
>>> > and drm_atomic_connector_get_property functions.
>>> >
>>>
>>> Thanks for sending this. We ran into some re-training awkwardness
>>> recently, and I
>>> was hoping for such a patch.
>>>
>>> > Cc: Jani Nikula 
>>> > Cc: Daniel Vetter 
>>> > Cc: Ville Syrjala 
>>> > Cc: Chris Wilson 
>>> > Signed-off-by: Manasi Navare 
>>> > ---
>>> >  drivers/gpu/drm/drm_atomic.c|  5 
>>> >  drivers/gpu/drm/drm_connector.c | 65 
>>> > +++--
>>> >  include/drm/drm_connector.h | 12 +++-
>>> >  include/drm/drm_mode_config.h   |  5 
>>> >  include/uapi/drm/drm_mode.h |  4 +++
>>> >  5 files changed, 88 insertions(+), 3 deletions(-)
>>> >
>>> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
>>> > index 89737e4..644d19f 100644
>>> > --- a/drivers/gpu/drm/drm_atomic.c
>>> > +++ b/drivers/gpu/drm/drm_atomic.c
>>> > @@ -1087,6 +1087,9 @@ int drm_atomic_connector_set_property(struct 
>>> > drm_connector *connector,
>>> >  * now?) atomic writes to DPMS property:
>>> >  */
>>> > return -EINVAL;
>>> > +   } else if (property == config->link_status_property) {
>>> > +   state->link_status = val;
>>
>> I think we should have a check here to make sure userspace never tries to
>> set this from "GOOD" to "BAD". "BAD" to "BAD" we need to allow, since with
>> atomic userspace is supposed to be able to just restore everything to what
>> it was.
>>
>> I don't think trying to set it to "BAD" should cause an error though, just
>> silently keep the link status at "GOOG". So:
>>
>> /* Never downgrade from GOOD to BAD on userspace's request here,
>>  * only hw issues can do that. */
>> if (state->link_status == GOOD)
>> return 0;
>
> Can we return an error if the transition is invalid?
>
>> state->link_status = val;
>> return 0;
>>
>>> > +   return 0;
>>> > } else if (connector->funcs->atomic_set_property) {
>>> > return connector->funcs->atomic_set_property(connector,
>>> > state, property, val);
>>> > @@ -1135,6 +1138,8 @@ static void drm_atomic_connector_print_state(struct 
>>> > drm_printer *p,
>>> > *val = (state->crtc) ? state->crtc->base.id : 0;
>>> > } else if (property == config->dpms_property) {
>>> > *val = connector->dpms;
>>> > +   } else if (property == config->link_status_property) {
>>> > +   *val = state->link_status;
>>> > } else if (connector->funcs->atomic_get_property) {
>>> > return connector->funcs->atomic_get_property(connector,
>>> > state, property, val);
>>> > diff --git a/drivers/gpu/drm/drm_connector.c 
>>> > b/drivers/gpu/drm/drm_connector.c
>>> > index 5a45262..4576c9f 100644
>>> > --- a/drivers/gpu/drm/drm_connector.c
>>> > +++ b/drivers/gpu/drm/drm_connector.c
>>> > @@ -243,6 +243,10 @@ int drm_connector_init(struct drm_device *dev,
>>> > drm_object_attach_property(>base,
>>> >   config->dpms_property, 0);
>>> >
>>> > +   drm_object_attach_property(>base,
>>> > +  config->link_status_property,
>>> > +  0);
>>> > +
>>> > if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
>>> > drm_object_attach_property(>base, 
>>> > config->prop_crtc_id, 0);
>>> > }
>>> > @@ -506,6 +510,12 @@ const char *drm_get_subpixel_order_name(enum 
>>> > subpixel_order order)
>>> >  };
>>> >  DRM_ENUM_NAME_FN(drm_get_dpms_name, drm_dpms_enum_list)
>>> >
>>> > +static const struct drm_prop_enum_list drm_link_status_enum_list[] = {
>>> > +   { DRM_MODE_LINK_STATUS_GOOD, "Good" },
>>> > +   { DRM_MODE_LINK_STATUS_BAD, "Bad" },
>>> > +};
>>> > +DRM_ENUM_NAME_FN(drm_get_link_status_name, drm_link_status_enum_list)
>>> > +
>>> >  /**
>>> >   * drm_display_info_set_bus_formats - set the supported bus formats
>>> >   * @info: display info to store bus formats in
>>> > @@ -616,7 +626,7 @@ int drm_display_info_set_bus_formats(struct 
>>> > drm_display_info *info,
>>> >   * path property the MST manager created. Userspace cannot change 
>>> > this
>>> >   * property.
>>> >   

[Intel-gfx] [PATCH v3] drm/i915/perf: Wrap 64bit divides in do_div()

[Chris Wilson]

Just a couple of naked 64bit divides causing link errors on 32bit
builds, with:

ERROR: "__udivdi3" [drivers/gpu/drm/i915/i915.ko] undefined!

v2: do_div() is only u64/u32, we need a u32/u64!
v3: div_u64() == u64/u32, div64_u64() == u64/u64

Reported-by: kbuild test robot 
Fixes: d79651522e89 ("drm/i915: Enable i915 perf stream for Haswell OA unit")
Signed-off-by: Chris Wilson 
Cc: Robert Bragg 
---
 drivers/gpu/drm/i915/i915_perf.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 95512824922b..14de9a4eee27 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -974,8 +974,8 @@ static void i915_oa_stream_disable(struct i915_perf_stream 
*stream)
 
 static u64 oa_exponent_to_ns(struct drm_i915_private *dev_priv, int exponent)
 {
-   return 10ULL * (2ULL << exponent) /
-   dev_priv->perf.oa.timestamp_frequency;
+   return div_u64(10ULL * (2ULL << exponent),
+  dev_priv->perf.oa.timestamp_frequency);
 }
 
 static const struct i915_perf_stream_ops i915_oa_stream_ops = {
@@ -1051,16 +1051,17 @@ static int i915_oa_stream_init(struct i915_perf_stream 
*stream,
 
dev_priv->perf.oa.periodic = props->oa_periodic;
if (dev_priv->perf.oa.periodic) {
-   u64 period_ns = oa_exponent_to_ns(dev_priv,
- props->oa_period_exponent);
+   u32 tail;
 
dev_priv->perf.oa.period_exponent = props->oa_period_exponent;
 
/* See comment for OA_TAIL_MARGIN_NSEC for details
 * about this tail_margin...
 */
-   dev_priv->perf.oa.tail_margin =
-   ((OA_TAIL_MARGIN_NSEC / period_ns) + 1) * format_size;
+   tail = div64_u64(OA_TAIL_MARGIN_NSEC,
+oa_exponent_to_ns(dev_priv,
+  props->oa_period_exponent));
+   dev_priv->perf.oa.tail_margin = (tail + 1) * format_size;
}
 
if (stream->ctx) {
-- 
2.10.2

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

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Add support for DP Video pattern compliance tests

[Ville Syrjälä]

On Wed, Nov 23, 2016 at 03:17:53PM +0100, Daniel Vetter wrote:
> On Wed, Nov 23, 2016 at 03:58:34PM +0200, Jani Nikula wrote:
> > On Wed, 23 Nov 2016, Ville Syrjälä  wrote:
> > > On Wed, Nov 23, 2016 at 03:37:24PM +0200, Jani Nikula wrote:
> > >> On Tue, 22 Nov 2016, Manasi Navare  wrote:
> > >> > The intel_dp_autotest_video_pattern() function gets invoked through the
> > >> > compliance test handler on a HPD short pulse if the test type is
> > >> > set to DP_TEST_VIDEO_PATTERN. This performs the DPCD registers
> > >> > reads to read the requested test pattern, video pattern resolution,
> > >> > frame rate and bits per color value. The results of this analysis
> > >> > are handed off to userspace so that the userspace app can set the
> > >> > video pattern mode appropriately for the test result/response.
> > >> >
> > >> > The compliance_test_active flag is set at the end of the individual
> > >> > test handling functions. This is so that the kernel-side operations
> > >> > can be completed without the risk of interruption from the userspace
> > >> > app that is polling on that flag.
> > >> 
> > >> I've brought this up before, but I think for this stuff the way to go is
> > >> to have the userspace read the DPCD directly. We have the dev node for
> > >> it.
> > >> 
> > >> With the approach in this patch, we'll just end up reading a bunch of
> > >> stuff from DPCD in kernel, doing error handling for that, decoding and
> > >> sanity checking the values, putting them in debugfs for the userspace to
> > >> read, having userspace code read debugfs, doing error handling for that,
> > >> decoding and sanity checking the data, finally doing something based on
> > >> the data.
> > >> 
> > >> You'll also get a *much* faster turnaround for getting your userspace
> > >> code done than getting all of this in kernel first, then tweaking your
> > >> userspace, having to update both of those in lockstep, etc. When this is
> > >> based on reading DPCD directly, you can just add new stuff quickly in
> > >> userspace, with no kernel dependency.
> > >> 
> > >> The easiest way would be to have an indication in debugfs for userspace
> > >> that there's something interesting in DPCD. Just a simple thing.
> > >
> > > Or just have the kernel fire off an uevent...
> > 
> > I know, I know, I had that written in my mail already, but swallowed it
> > not to add another dependency on another new UABI... we can do that
> > later.
> 
> In principle I'd agree, but the trouble with dp compliance is that the CTS
> expects us to do stupid shit sometimes, like that test pattern forced as
> 6bpc. So if we decode everything in userspace then the question is
> how to feed all those special cases back into the kernel, which means more
> debugfs interfaces. Just going in the other direction.
> 
> Given that it's a bit a toss-up unfortunately, and the current approach
> seems reasonable.

The kernel could of course parse whatever is needed from the test
request as well, but leave it up to userspace to initiate the actual
test and ack/nack the test request. So I don't see a real need for
a debugfs interface in either direction.

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

[Intel-gfx] [PATCH v2] drm/i915: Remove all ->config dereferences from intel_hdmi, v2.

[Maarten Lankhorst]

In all cases we can now obtain the relevant crtc_state/conn_state
from the relevant callbacks, which means all the ->config accesses
can be removed and the code cleaned up.

Changes since v1:
- cstate -> crtc_state

Signed-off-by: Maarten Lankhorst 
---
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 10ec9d4b7d45..0d680dabac77 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1701,7 +1701,8 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder 
*encoder,
 
 static void intel_ddi_pre_enable_hdmi(struct intel_encoder *encoder,
  bool has_hdmi_sink,
- struct drm_display_mode *adjusted_mode,
+ const struct intel_crtc_state *crtc_state,
+ const struct drm_connector_state 
*conn_state,
  struct intel_shared_dpll *pll)
 {
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(>base);
@@ -1721,7 +1722,7 @@ static void intel_ddi_pre_enable_hdmi(struct 
intel_encoder *encoder,
 
intel_hdmi->set_infoframes(drm_encoder,
   has_hdmi_sink,
-  adjusted_mode);
+  crtc_state, conn_state);
 }
 
 static void intel_ddi_pre_enable(struct intel_encoder *intel_encoder,
@@ -1742,8 +1743,8 @@ static void intel_ddi_pre_enable(struct intel_encoder 
*intel_encoder,
}
if (type == INTEL_OUTPUT_HDMI) {
intel_ddi_pre_enable_hdmi(intel_encoder,
- crtc->config->has_hdmi_sink,
- >config->base.adjusted_mode,
+ pipe_config->has_hdmi_sink,
+ pipe_config, conn_state,
  crtc->config->shared_dpll);
}
 }
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index cd132c216a67..20dff1837c5d 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -840,11 +840,13 @@ struct intel_hdmi {
enum hdmi_picture_aspect aspect_ratio;
struct intel_connector *attached_connector;
void (*write_infoframe)(struct drm_encoder *encoder,
+   const struct intel_crtc_state *crtc_state,
enum hdmi_infoframe_type type,
const void *frame, ssize_t len);
void (*set_infoframes)(struct drm_encoder *encoder,
   bool enable,
-  const struct drm_display_mode *adjusted_mode);
+  const struct intel_crtc_state *crtc_state,
+  const struct drm_connector_state *conn_state);
bool (*infoframe_enabled)(struct drm_encoder *encoder,
  const struct intel_crtc_state *pipe_config);
 };
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index fb88e32e25a3..bb29230e021a 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -133,6 +133,7 @@ hsw_dip_data_reg(struct drm_i915_private *dev_priv,
 }
 
 static void g4x_write_infoframe(struct drm_encoder *encoder,
+   const struct intel_crtc_state *crtc_state,
enum hdmi_infoframe_type type,
const void *frame, ssize_t len)
 {
@@ -187,13 +188,14 @@ static bool g4x_infoframe_enabled(struct drm_encoder 
*encoder,
 }
 
 static void ibx_write_infoframe(struct drm_encoder *encoder,
+   const struct intel_crtc_state *crtc_state,
enum hdmi_infoframe_type type,
const void *frame, ssize_t len)
 {
const uint32_t *data = frame;
struct drm_device *dev = encoder->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
-   struct intel_crtc *intel_crtc = to_intel_crtc(encoder->crtc);
+   struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->base.crtc);
i915_reg_t reg = TVIDEO_DIP_CTL(intel_crtc->pipe);
u32 val = I915_READ(reg);
int i;
@@ -246,13 +248,14 @@ static bool ibx_infoframe_enabled(struct drm_encoder 
*encoder,
 }
 
 static void cpt_write_infoframe(struct drm_encoder *encoder,
+   const struct intel_crtc_state *crtc_state,
enum hdmi_infoframe_type type,
const void *frame, ssize_t len)
 {
const uint32_t *data = frame;
struct drm_device *dev = encoder->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
-   struct intel_crtc *intel_crtc = to_intel_crtc(encoder->crtc);
+  

Re: [Intel-gfx] [PATCH RFC] drm: Add a new connector atomic property for link status

[Sean Paul]

On Wed, Nov 23, 2016 at 3:09 AM, Daniel Vetter  wrote:
> On Tue, Nov 22, 2016 at 09:27:35PM -0500, Sean Paul wrote:
>> On Tue, Nov 22, 2016 at 8:30 PM, Manasi Navare
>>  wrote:
>> > This is RFC patch for adding a connector link-status property
>> > and making it atomic by adding it to the drm_connector_state.
>> > This is to make sure its wired properly in 
>> > drm_atomic_connector_set_property
>> > and drm_atomic_connector_get_property functions.
>> >
>>
>> Thanks for sending this. We ran into some re-training awkwardness
>> recently, and I
>> was hoping for such a patch.
>>
>> > Cc: Jani Nikula 
>> > Cc: Daniel Vetter 
>> > Cc: Ville Syrjala 
>> > Cc: Chris Wilson 
>> > Signed-off-by: Manasi Navare 
>> > ---
>> >  drivers/gpu/drm/drm_atomic.c|  5 
>> >  drivers/gpu/drm/drm_connector.c | 65 
>> > +++--
>> >  include/drm/drm_connector.h | 12 +++-
>> >  include/drm/drm_mode_config.h   |  5 
>> >  include/uapi/drm/drm_mode.h |  4 +++
>> >  5 files changed, 88 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
>> > index 89737e4..644d19f 100644
>> > --- a/drivers/gpu/drm/drm_atomic.c
>> > +++ b/drivers/gpu/drm/drm_atomic.c
>> > @@ -1087,6 +1087,9 @@ int drm_atomic_connector_set_property(struct 
>> > drm_connector *connector,
>> >  * now?) atomic writes to DPMS property:
>> >  */
>> > return -EINVAL;
>> > +   } else if (property == config->link_status_property) {
>> > +   state->link_status = val;
>
> I think we should have a check here to make sure userspace never tries to
> set this from "GOOD" to "BAD". "BAD" to "BAD" we need to allow, since with
> atomic userspace is supposed to be able to just restore everything to what
> it was.
>
> I don't think trying to set it to "BAD" should cause an error though, just
> silently keep the link status at "GOOG". So:
>
> /* Never downgrade from GOOD to BAD on userspace's request here,
>  * only hw issues can do that. */
> if (state->link_status == GOOD)
> return 0;

Can we return an error if the transition is invalid?

> state->link_status = val;
> return 0;
>
>> > +   return 0;
>> > } else if (connector->funcs->atomic_set_property) {
>> > return connector->funcs->atomic_set_property(connector,
>> > state, property, val);
>> > @@ -1135,6 +1138,8 @@ static void drm_atomic_connector_print_state(struct 
>> > drm_printer *p,
>> > *val = (state->crtc) ? state->crtc->base.id : 0;
>> > } else if (property == config->dpms_property) {
>> > *val = connector->dpms;
>> > +   } else if (property == config->link_status_property) {
>> > +   *val = state->link_status;
>> > } else if (connector->funcs->atomic_get_property) {
>> > return connector->funcs->atomic_get_property(connector,
>> > state, property, val);
>> > diff --git a/drivers/gpu/drm/drm_connector.c 
>> > b/drivers/gpu/drm/drm_connector.c
>> > index 5a45262..4576c9f 100644
>> > --- a/drivers/gpu/drm/drm_connector.c
>> > +++ b/drivers/gpu/drm/drm_connector.c
>> > @@ -243,6 +243,10 @@ int drm_connector_init(struct drm_device *dev,
>> > drm_object_attach_property(>base,
>> >   config->dpms_property, 0);
>> >
>> > +   drm_object_attach_property(>base,
>> > +  config->link_status_property,
>> > +  0);
>> > +
>> > if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
>> > drm_object_attach_property(>base, 
>> > config->prop_crtc_id, 0);
>> > }
>> > @@ -506,6 +510,12 @@ const char *drm_get_subpixel_order_name(enum 
>> > subpixel_order order)
>> >  };
>> >  DRM_ENUM_NAME_FN(drm_get_dpms_name, drm_dpms_enum_list)
>> >
>> > +static const struct drm_prop_enum_list drm_link_status_enum_list[] = {
>> > +   { DRM_MODE_LINK_STATUS_GOOD, "Good" },
>> > +   { DRM_MODE_LINK_STATUS_BAD, "Bad" },
>> > +};
>> > +DRM_ENUM_NAME_FN(drm_get_link_status_name, drm_link_status_enum_list)
>> > +
>> >  /**
>> >   * drm_display_info_set_bus_formats - set the supported bus formats
>> >   * @info: display info to store bus formats in
>> > @@ -616,7 +626,7 @@ int drm_display_info_set_bus_formats(struct 
>> > drm_display_info *info,
>> >   * path property the MST manager created. Userspace cannot change this
>> >   * property.
>> >   * TILE:
>> > - * Connector tile group property to indicate how a set of DRM 
>> > connector
>> > + *  Connector tile group property to indicate how a set of DRM 
>> > 

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Remove unused intel_guc_fw struct member

[Tvrtko Ursulin]

On 23/11/2016 10:45, Patchwork wrote:

== Series Details ==

Series: drm/i915/guc: Remove unused intel_guc_fw struct member
URL   : https://patchwork.freedesktop.org/series/15803/
State : success

== Summary ==

Series 15803v1 drm/i915/guc: Remove unused intel_guc_fw struct member
https://patchwork.freedesktop.org/api/1.0/series/15803/revisions/1/mbox/


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

d8db619985b5a8e4416ab78017ea9252e7f24689 drm-intel-nightly: 
2016y-11m-23d-07h-34m-41s UTC integration manifest
6e195ce drm/i915/guc: Remove unused intel_guc_fw struct member


Pushed, 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] ✓ Fi.CI.BAT: success for drm/i915: i915_gem_alloc_context_obj can be static (rev2)

[Tvrtko Ursulin]

On 23/11/2016 11:15, Patchwork wrote:

== Series Details ==

Series: drm/i915: i915_gem_alloc_context_obj can be static (rev2)
URL   : https://patchwork.freedesktop.org/series/15804/
State : success

== Summary ==

Series 15804v2 drm/i915: i915_gem_alloc_context_obj can be static
https://patchwork.freedesktop.org/api/1.0/series/15804/revisions/2/mbox/


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

d8db619985b5a8e4416ab78017ea9252e7f24689 drm-intel-nightly: 
2016y-11m-23d-07h-34m-41s UTC integration manifest
0ff8a90 drm/i915: i915_gem_alloc_context_obj can be static


Pushed, 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 v2] drm/i915: Pass dev_priv to intel_setup_outputs()

[Ander Conselvan de Oliveira]

Pass dev_priv to intel_setup_outputs() and functions called by it, since
those are all intel i915 specific functions. Also, in the majority of
the functions dev_priv is used more often than dev. In the rare cases
where there are a few calls back into drm core, a local dev variable was
added.

v2: Don't convert dev to _priv->drm in intel_dsi_init. (Ville)
Signed-off-by: Ander Conselvan de Oliveira 

---
 drivers/gpu/drm/i915/i915_drv.c  |   4 +-
 drivers/gpu/drm/i915/i915_drv.h  |   2 +-
 drivers/gpu/drm/i915/intel_crt.c |   7 +-
 drivers/gpu/drm/i915/intel_ddi.c |   5 +-
 drivers/gpu/drm/i915/intel_display.c | 120 ---
 drivers/gpu/drm/i915/intel_dp.c  |   8 +--
 drivers/gpu/drm/i915/intel_drv.h |  22 ---
 drivers/gpu/drm/i915/intel_dsi.c |   4 +-
 drivers/gpu/drm/i915/intel_dvo.c |   9 ++-
 drivers/gpu/drm/i915/intel_hdmi.c|   8 +--
 drivers/gpu/drm/i915/intel_lvds.c|   4 +-
 drivers/gpu/drm/i915/intel_psr.c |   4 +-
 drivers/gpu/drm/i915/intel_sdvo.c|  19 +++---
 drivers/gpu/drm/i915/intel_tv.c  |   4 +-
 14 files changed, 105 insertions(+), 115 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 445fec9..5917af1 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1571,7 +1571,7 @@ static int i915_drm_resume(struct drm_device *dev)
intel_pps_unlock_regs_wa(dev_priv);
intel_opregion_setup(dev_priv);
 
-   intel_init_pch_refclk(dev);
+   intel_init_pch_refclk(dev_priv);
drm_mode_config_reset(dev);
 
/*
@@ -2408,7 +2408,7 @@ static int intel_runtime_resume(struct device *kdev)
intel_guc_resume(dev);
 
if (IS_GEN6(dev_priv))
-   intel_init_pch_refclk(dev);
+   intel_init_pch_refclk(dev_priv);
 
if (IS_BROXTON(dev_priv)) {
bxt_disable_dc9(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index be67aee..c0d0a0d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3487,7 +3487,7 @@ extern void intel_display_resume(struct drm_device *dev);
 extern void i915_redisable_vga(struct drm_i915_private *dev_priv);
 extern void i915_redisable_vga_power_on(struct drm_i915_private *dev_priv);
 extern bool ironlake_set_drps(struct drm_i915_private *dev_priv, u8 val);
-extern void intel_init_pch_refclk(struct drm_device *dev);
+extern void intel_init_pch_refclk(struct drm_i915_private *dev_priv);
 extern void intel_set_rps(struct drm_i915_private *dev_priv, u8 val);
 extern void intel_set_memory_cxsr(struct drm_i915_private *dev_priv,
  bool enable);
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 86ecec5..385e29a 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -836,12 +836,11 @@ static const struct drm_encoder_funcs intel_crt_enc_funcs 
= {
.destroy = intel_encoder_destroy,
 };
 
-void intel_crt_init(struct drm_device *dev)
+void intel_crt_init(struct drm_i915_private *dev_priv)
 {
struct drm_connector *connector;
struct intel_crt *crt;
struct intel_connector *intel_connector;
-   struct drm_i915_private *dev_priv = to_i915(dev);
i915_reg_t adpa_reg;
u32 adpa;
 
@@ -881,10 +880,10 @@ void intel_crt_init(struct drm_device *dev)
 
connector = _connector->base;
crt->connector = intel_connector;
-   drm_connector_init(dev, _connector->base,
+   drm_connector_init(_priv->drm, _connector->base,
   _crt_connector_funcs, DRM_MODE_CONNECTOR_VGA);
 
-   drm_encoder_init(dev, >base.base, _crt_enc_funcs,
+   drm_encoder_init(_priv->drm, >base.base, _crt_enc_funcs,
 DRM_MODE_ENCODER_DAC, "CRT");
 
intel_connector_attach_encoder(intel_connector, >base);
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 10ec9d4..a45dc37 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2154,9 +2154,8 @@ intel_ddi_get_link_dpll(struct intel_dp *intel_dp, int 
clock)
return pll;
 }
 
-void intel_ddi_init(struct drm_device *dev, enum port port)
+void intel_ddi_init(struct drm_i915_private *dev_priv, enum port port)
 {
-   struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_digital_port *intel_dig_port;
struct intel_encoder *intel_encoder;
struct drm_encoder *encoder;
@@ -2218,7 +2217,7 @@ void intel_ddi_init(struct drm_device *dev, enum port 
port)
intel_encoder = _dig_port->base;
encoder = _encoder->base;
 
-   drm_encoder_init(dev, encoder, _ddi_funcs,
+   drm_encoder_init(_priv->drm, encoder, _ddi_funcs,
 DRM_MODE_ENCODER_TMDS, "DDI %c", port_name(port));
 
 

Re: [Intel-gfx] [PATCH 1/3] drm: Hold mode_config.lock to prevent hotplug whilst setting up crtcs

[Jani Nikula]

On Wed, 23 Nov 2016, Chris Wilson  wrote:
> +#define drm_fb_helper_for_each_connector(fbh, i__) \
> + for (({lockdep_assert_held(&(fbh)->dev->mode_config.mutex); 1;}), \
> +  i__ = 0; i__ < (fbh)->connector_count; i__++)

No comments on the substance, but just curious, why is that "1;"
required there? Or is it?

BR,
Jani.

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

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Add support for DP Video pattern compliance tests

[Daniel Vetter]

On Wed, Nov 23, 2016 at 03:58:34PM +0200, Jani Nikula wrote:
> On Wed, 23 Nov 2016, Ville Syrjälä  wrote:
> > On Wed, Nov 23, 2016 at 03:37:24PM +0200, Jani Nikula wrote:
> >> On Tue, 22 Nov 2016, Manasi Navare  wrote:
> >> > The intel_dp_autotest_video_pattern() function gets invoked through the
> >> > compliance test handler on a HPD short pulse if the test type is
> >> > set to DP_TEST_VIDEO_PATTERN. This performs the DPCD registers
> >> > reads to read the requested test pattern, video pattern resolution,
> >> > frame rate and bits per color value. The results of this analysis
> >> > are handed off to userspace so that the userspace app can set the
> >> > video pattern mode appropriately for the test result/response.
> >> >
> >> > The compliance_test_active flag is set at the end of the individual
> >> > test handling functions. This is so that the kernel-side operations
> >> > can be completed without the risk of interruption from the userspace
> >> > app that is polling on that flag.
> >> 
> >> I've brought this up before, but I think for this stuff the way to go is
> >> to have the userspace read the DPCD directly. We have the dev node for
> >> it.
> >> 
> >> With the approach in this patch, we'll just end up reading a bunch of
> >> stuff from DPCD in kernel, doing error handling for that, decoding and
> >> sanity checking the values, putting them in debugfs for the userspace to
> >> read, having userspace code read debugfs, doing error handling for that,
> >> decoding and sanity checking the data, finally doing something based on
> >> the data.
> >> 
> >> You'll also get a *much* faster turnaround for getting your userspace
> >> code done than getting all of this in kernel first, then tweaking your
> >> userspace, having to update both of those in lockstep, etc. When this is
> >> based on reading DPCD directly, you can just add new stuff quickly in
> >> userspace, with no kernel dependency.
> >> 
> >> The easiest way would be to have an indication in debugfs for userspace
> >> that there's something interesting in DPCD. Just a simple thing.
> >
> > Or just have the kernel fire off an uevent...
> 
> I know, I know, I had that written in my mail already, but swallowed it
> not to add another dependency on another new UABI... we can do that
> later.

In principle I'd agree, but the trouble with dp compliance is that the CTS
expects us to do stupid shit sometimes, like that test pattern forced as
6bpc. So if we decode everything in userspace then the question is
how to feed all those special cases back into the kernel, which means more
debugfs interfaces. Just going in the other direction.

Given that it's a bit a toss-up unfortunately, and the current approach
seems reasonable.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Moving scaler numbers to runtime init (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: Moving scaler numbers to runtime init (rev3)
URL   : https://patchwork.freedesktop.org/series/15726/
State : success

== Summary ==

Series 15726v3 drm/i915: Moving scaler numbers to runtime init
https://patchwork.freedesktop.org/api/1.0/series/15726/revisions/3/mbox/


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

e982799174795e1cccb77845051722c1616c03fd drm-intel-nightly: 
2016y-11m-23d-11h-32m-46s UTC integration manifest
78aefd1 drm/i915: Move number of scalers initialization to runtime init

== Logs ==

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

[Intel-gfx] [PATCH 5/5] drm/i915: Tidy i915_gem_valid_gtt_space()

[Chris Wilson]

We can replace a couple of tests with an assertion that the passed in
node is already allocated (as matches the existing call convention) and
by a small bit of refactoring we can bring the line lengths to under
80cols.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_vma.c | 23 +--
 1 file changed, 13 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 19f17b02f4a0..da50be488861 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -297,10 +297,15 @@ void __i915_vma_set_map_and_fenceable(struct i915_vma 
*vma)
vma->flags &= ~I915_VMA_CAN_FENCE;
 }
 
+static bool color_differs(struct drm_mm_node *node, unsigned long color)
+{
+   return node->allocated && node->color != color;
+}
+
 bool i915_gem_valid_gtt_space(struct i915_vma *vma,
  unsigned long cache_level)
 {
-   struct drm_mm_node *gtt_space = >node;
+   struct drm_mm_node *node = >node;
struct drm_mm_node *other;
 
/*
@@ -313,18 +318,16 @@ bool i915_gem_valid_gtt_space(struct i915_vma *vma,
if (vma->vm->mm.color_adjust == NULL)
return true;
 
-   if (!drm_mm_node_allocated(gtt_space))
-   return true;
-
-   if (list_empty(_space->node_list))
-   return true;
+   /* Only valid to be called on an already inserted vma */
+   GEM_BUG_ON(!drm_mm_node_allocated(node));
+   GEM_BUG_ON(list_empty(>node_list));
 
-   other = list_entry(gtt_space->node_list.prev, struct drm_mm_node, 
node_list);
-   if (other->allocated && !other->hole_follows && other->color != 
cache_level)
+   other = list_prev_entry(node, node_list);
+   if (color_differs(other, cache_level) && !other->hole_follows)
return false;
 
-   other = list_entry(gtt_space->node_list.next, struct drm_mm_node, 
node_list);
-   if (other->allocated && !gtt_space->hole_follows && other->color != 
cache_level)
+   other = list_next_entry(node, node_list);
+   if (color_differs(other, cache_level) && !node->hole_follows)
return false;
 
return true;
-- 
2.10.2

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

[Intel-gfx] [PATCH 4/5] drm/i915: Fix i915_gem_evict_for_vma (soft-pinning)

[Chris Wilson]

Soft-pinning depends upon being able to check for availabilty of an
interval and evict overlapping object from a drm_mm range manager very
quickly. Currently it uses a linear list, and so performance is dire and
not suitable as a general replacement. Worse, the current code will oops
if it tries to evict an active buffer.

It also helps if the routine reports the correct error codes as expected
by its callers and emits a tracepoint upon use.

For posterity since the wrong patch was pushed (i.e. that missed these
key points and had known bugs), this is the changelog that should have
been on commit 506a8e87d8d2 ("drm/i915: Add soft-pinning API for
execbuffer"):

Userspace can pass in an offset that it presumes the object is located
at. The kernel will then do its utmost to fit the object into that
location. The assumption is that userspace is handling its own object
locations (for example along with full-ppgtt) and that the kernel will
rarely have to make space for the user's requests.

This extends the DRM_IOCTL_I915_GEM_EXECBUFFER2 to do the following:
* if the user supplies a virtual address via the execobject->offset
  *and* sets the EXEC_OBJECT_PINNED flag in execobject->flags, then
  that object is placed at that offset in the address space selected
  by the context specifier in execbuffer.
* the location must be aligned to the GTT page size, 4096 bytes
* as the object is placed exactly as specified, it may be used by this
  execbuffer call without relocations pointing to it

It may fail to do so if:
* EINVAL is returned if the object does not have a 4096 byte aligned
  address
* the object conflicts with another pinned object (either pinned by
  hardware in that address space, e.g. scanouts in the aliasing ppgtt)
  or within the same batch.
  EBUSY is returned if the location is pinned by hardware
  EINVAL is returned if the location is already in use by the batch
* EINVAL is returned if the object conflicts with its own alignment (as meets
  the hardware requirements) or if the placement of the object does not fit
  within the address space

All other execbuffer errors apply.

Presence of this execbuf extension may be queried by passing
I915_PARAM_HAS_EXEC_SOFTPIN to DRM_IOCTL_I915_GETPARAM and checking for
a reported value of 1 (or greater).

v2: Combine the hole/adjusted-hole ENOSPC checks
v3: More color, more splitting, more blurb.

Fixes: 506a8e87d8d2 ("drm/i915: Add soft-pinning API for execbuffer")
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h|   3 +-
 drivers/gpu/drm/i915/i915_gem_evict.c  | 104 ++---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |   1 +
 drivers/gpu/drm/i915/i915_trace.h  |  23 +++
 drivers/gpu/drm/i915/i915_vma.c|   2 +-
 5 files changed, 106 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b8e65b189635..423665904e0d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3410,7 +3410,8 @@ int __must_check i915_gem_evict_something(struct 
i915_address_space *vm,
  unsigned cache_level,
  u64 start, u64 end,
  unsigned flags);
-int __must_check i915_gem_evict_for_vma(struct i915_vma *target);
+int __must_check i915_gem_evict_for_vma(struct i915_vma *vma,
+   unsigned int flags);
 int i915_gem_evict_vm(struct i915_address_space *vm, bool do_idle);
 
 /* belongs in i915_gem_gtt.h */
diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c 
b/drivers/gpu/drm/i915/i915_gem_evict.c
index bd08814b015c..e6104c659e3e 100644
--- a/drivers/gpu/drm/i915/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/i915_gem_evict.c
@@ -212,45 +212,99 @@ i915_gem_evict_something(struct i915_address_space *vm,
return ret;
 }
 
-int
-i915_gem_evict_for_vma(struct i915_vma *target)
+/**
+ * i915_gem_evict_for_vma - Evict vmas to make room for binding a new one
+ * @target: address space and range to evict for
+ * @flags: additional flags to control the eviction algorithm
+ *
+ * This function will try to evict vmas that overlap the target node.
+ *
+ * To clarify: This is for freeing up virtual address space, not for freeing
+ * memory in e.g. the shrinker.
+ */
+int i915_gem_evict_for_vma(struct i915_vma *target, unsigned int flags)
 {
-   struct drm_mm_node *node, *next;
+   LIST_HEAD(eviction_list);
+   struct drm_mm_node *node;
+   u64 start = target->node.start;
+   u64 end = start + target->node.size;
+   struct i915_vma *vma, *next;
+   bool check_color;
+   int ret = 0;
 
lockdep_assert_held(>vm->dev->struct_mutex);
+   trace_i915_gem_evict_vma(target, flags);
+
+   check_color = target->vm->mm.color_adjust;
+   if (check_color) {
+   /* Expand search to cover neighbouring guard 

[Intel-gfx] [PATCH 1/5] drm: Define drm_mm_for_each_node_in_range()

[Chris Wilson]

Some clients would like to iterate over every node within a certain
range. Make a nice little macro for them to hide the mixing of the
rbtree search and linear walk.

v2: Blurb

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: dri-de...@lists.freedesktop.org
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/drm_mm.c | 11 ++-
 include/drm/drm_mm.h | 22 +++---
 2 files changed, 21 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 632473beb40c..f8eebbde376e 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -174,19 +174,12 @@ INTERVAL_TREE_DEFINE(struct drm_mm_node, rb,
 START, LAST, static inline, drm_mm_interval_tree)
 
 struct drm_mm_node *
-drm_mm_interval_first(struct drm_mm *mm, u64 start, u64 last)
+__drm_mm_interval_first(struct drm_mm *mm, u64 start, u64 last)
 {
return drm_mm_interval_tree_iter_first(>interval_tree,
   start, last);
 }
-EXPORT_SYMBOL(drm_mm_interval_first);
-
-struct drm_mm_node *
-drm_mm_interval_next(struct drm_mm_node *node, u64 start, u64 last)
-{
-   return drm_mm_interval_tree_iter_next(node, start, last);
-}
-EXPORT_SYMBOL(drm_mm_interval_next);
+EXPORT_SYMBOL(__drm_mm_interval_first);
 
 static void drm_mm_interval_tree_add_node(struct drm_mm_node *hole_node,
  struct drm_mm_node *node)
diff --git a/include/drm/drm_mm.h b/include/drm/drm_mm.h
index 41ddafe92b2f..6add455c651b 100644
--- a/include/drm/drm_mm.h
+++ b/include/drm/drm_mm.h
@@ -308,10 +308,26 @@ void drm_mm_takedown(struct drm_mm *mm);
 bool drm_mm_clean(struct drm_mm *mm);
 
 struct drm_mm_node *
-drm_mm_interval_first(struct drm_mm *mm, u64 start, u64 last);
+__drm_mm_interval_first(struct drm_mm *mm, u64 start, u64 last);
 
-struct drm_mm_node *
-drm_mm_interval_next(struct drm_mm_node *node, u64 start, u64 last);
+/**
+ * drm_mm_for_each_node_in_range - iterator to walk over a range of
+ * allocated nodes
+ * @node: drm_mm_node structure to assign to in each iteration step
+ * @mm: drm_mm allocator to walk
+ * @start: starting offset, the first node will overlap this
+ * @end: ending offset, the last node will start before this (but may overlap)
+ *
+ * This iterator walks over all nodes in the range allocator that lie
+ * between @start and @end. It is implemented similarly to list_for_each(),
+ * but using the internal interval tree to accelerate the search for the
+ * starting node, and so not safe against removal of elements. It assumes
+ * that @end is within (or is the upper limit of) the drm_mm allocator.
+ */
+#define drm_mm_for_each_node_in_range(node, mm, start, end)\
+   for (node = __drm_mm_interval_first((mm), (start), (end)-1);\
+node && node->start < (end);   \
+node = list_next_entry(node, node_list))   \
 
 void drm_mm_init_scan(struct drm_mm *mm,
  u64 size,
-- 
2.10.2

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

[Intel-gfx] [PATCH 3/5] drm/i915: Mark all non-vma being inserted into the address spaces

[Chris Wilson]

We need to distinguish between full i915_vma structs and simple
drm_mm_nodes when considering eviction (i.e. we must be careful not to
treat a mere drm_mm_node as a much larger i915_vma causing memory
corruption, if we are lucky). To do this, color these not-a-vma with -1
(I915_COLOR_UNEVICTABLE).

v2...v200: New name for -1.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/gvt/aperture_gm.c |  7 +--
 drivers/gpu/drm/i915/i915_drv.h|  1 +
 drivers/gpu/drm/i915/i915_gem.c|  3 ++-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  2 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c| 11 ++-
 5 files changed, 15 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/aperture_gm.c 
b/drivers/gpu/drm/i915/gvt/aperture_gm.c
index 0d41ebc4aea6..7d33b607bc89 100644
--- a/drivers/gpu/drm/i915/gvt/aperture_gm.c
+++ b/drivers/gpu/drm/i915/gvt/aperture_gm.c
@@ -73,12 +73,15 @@ static int alloc_gm(struct intel_vgpu *vgpu, bool high_gm)
mutex_lock(_priv->drm.struct_mutex);
 search_again:
ret = drm_mm_insert_node_in_range_generic(_priv->ggtt.base.mm,
- node, size, 4096, 0,
+ node, size, 4096,
+ I915_COLOR_UNEVICTABLE,
  start, end, search_flag,
  alloc_flag);
if (ret) {
ret = i915_gem_evict_something(_priv->ggtt.base,
-  size, 4096, 0, start, end, 0);
+  size, 4096,
+  I915_COLOR_UNEVICTABLE,
+  start, end, 0);
if (ret == 0 && ++retried < 3)
goto search_again;
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 970e50bf9884..b8e65b189635 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -912,6 +912,7 @@ enum i915_cache_level {
  the CPU, but L3 is only visible to the GPU. */
I915_CACHE_WT, /* hsw:gt3e WriteThrough for scanouts */
 };
+#define I915_COLOR_UNEVICTABLE (-1) /* a non-vma sharing the address space */
 
 #define DEFAULT_CONTEXT_HANDLE 0
 
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 3d4e07e9734f..097b3154b0ef 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -70,7 +70,8 @@ insert_mappable_node(struct i915_ggtt *ggtt,
 {
memset(node, 0, sizeof(*node));
return drm_mm_insert_node_in_range_generic(>base.mm, node,
-  size, 0, -1,
+  size, 0,
+  I915_COLOR_UNEVICTABLE,
   0, ggtt->mappable_end,
   DRM_MM_SEARCH_DEFAULT,
   DRM_MM_CREATE_DEFAULT);
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 522ecfb4dc9d..8ad6a64c9e01 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -437,7 +437,7 @@ static void *reloc_iomap(struct drm_i915_gem_object *obj,
memset(>node, 0, sizeof(cache->node));
ret = drm_mm_insert_node_in_range_generic
(>base.mm, >node,
-4096, 0, 0,
+4096, 0, I915_COLOR_UNEVICTABLE,
 0, ggtt->mappable_end,
 DRM_MM_SEARCH_DEFAULT,
 DRM_MM_CREATE_DEFAULT);
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index b4bde1452f2a..bc210c5ecc13 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2076,15 +2076,15 @@ static int gen6_ppgtt_allocate_page_directories(struct 
i915_hw_ppgtt *ppgtt)
return ret;
 
 alloc:
-   ret = drm_mm_insert_node_in_range_generic(>base.mm,
- >node, GEN6_PD_SIZE,
- GEN6_PD_ALIGN, 0,
+   ret = drm_mm_insert_node_in_range_generic(>base.mm, >node,
+ GEN6_PD_SIZE, GEN6_PD_ALIGN,
+ I915_COLOR_UNEVICTABLE,
  0, ggtt->base.total,
  DRM_MM_TOPDOWN);
if (ret == -ENOSPC && !retried) {
ret = 

[Intel-gfx] [PATCH 2/5] drm: Check against color expansion in drm_mm_reserve_node()

[Chris Wilson]

Use the color_adjust callback when reserving a node to check if
inserting a node into this hole requires any additional space, and so if
that space then conflicts with an existing allocation.

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: dri-de...@lists.freedesktop.org
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/drm_mm.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index f8eebbde376e..025dcd8cadcb 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -306,6 +306,7 @@ int drm_mm_reserve_node(struct drm_mm *mm, struct 
drm_mm_node *node)
u64 end = node->start + node->size;
struct drm_mm_node *hole;
u64 hole_start, hole_end;
+   u64 adj_start, adj_end;
 
if (WARN_ON(node->size == 0))
return -EINVAL;
@@ -327,9 +328,13 @@ int drm_mm_reserve_node(struct drm_mm *mm, struct 
drm_mm_node *node)
if (!hole->hole_follows)
return -ENOSPC;
 
-   hole_start = __drm_mm_hole_node_start(hole);
-   hole_end = __drm_mm_hole_node_end(hole);
-   if (hole_start > node->start || hole_end < end)
+   adj_start = hole_start = __drm_mm_hole_node_start(hole);
+   adj_end = hole_end = __drm_mm_hole_node_end(hole);
+
+   if (mm->color_adjust)
+   mm->color_adjust(hole, node->color, _start, _end);
+
+   if (adj_start > node->start || adj_end < end)
return -ENOSPC;
 
node->mm = mm;
-- 
2.10.2

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

[Intel-gfx] [PATCH 2/3] drm: Pull together probe + setup for drm_fb_helper

[Chris Wilson]

drm_fb_helper_probe_connector_modes() is always called before
drm_setup_crtcs(), so just move the call into drm_setup_crtcs for a
small bit of code compaction.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/drm_fb_helper.c | 37 +++--
 1 file changed, 11 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index d13c85682891..a19afc7eccde 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2098,20 +2098,19 @@ static int drm_pick_crtcs(struct drm_fb_helper 
*fb_helper,
return best_score;
 }
 
-static void drm_setup_crtcs(struct drm_fb_helper *fb_helper)
+static void drm_setup_crtcs(struct drm_fb_helper *fb_helper,
+   u32 width, u32 height)
 {
struct drm_device *dev = fb_helper->dev;
struct drm_fb_helper_crtc **crtcs;
struct drm_display_mode **modes;
struct drm_fb_offset *offsets;
bool *enabled;
-   int width, height;
int i;
 
DRM_DEBUG_KMS("\n");
-
-   width = dev->mode_config.max_width;
-   height = dev->mode_config.max_height;
+   if (drm_fb_helper_probe_connector_modes(fb_helper, width, height) == 0)
+   DRM_DEBUG_KMS("No connectors reported connected with modes\n");
 
/* prevent concurrent modification of connector_count by hotplug */
lockdep_assert_held(_helper->dev->mode_config.mutex);
@@ -2235,23 +2234,15 @@ int drm_fb_helper_initial_config(struct drm_fb_helper 
*fb_helper, int bpp_sel)
 {
struct drm_device *dev = fb_helper->dev;
struct fb_info *info;
-   int count = 0;
int ret;
 
if (!drm_fbdev_emulation)
return 0;
 
mutex_lock(>mode_config.mutex);
-   count = drm_fb_helper_probe_connector_modes(fb_helper,
-   dev->mode_config.max_width,
-   
dev->mode_config.max_height);
-   /*
-* we shouldn't end up with no modes here.
-*/
-   if (count == 0)
-   dev_info(fb_helper->dev->dev, "No connectors reported connected 
with modes\n");
-
-   drm_setup_crtcs(fb_helper);
+   drm_setup_crtcs(fb_helper,
+   dev->mode_config.max_width,
+   dev->mode_config.max_height);
ret = drm_fb_helper_single_fb_probe(fb_helper, bpp_sel);
mutex_unlock(>mode_config.mutex);
if (ret)
@@ -2299,28 +2290,22 @@ EXPORT_SYMBOL(drm_fb_helper_initial_config);
 int drm_fb_helper_hotplug_event(struct drm_fb_helper *fb_helper)
 {
struct drm_device *dev = fb_helper->dev;
-   u32 max_width, max_height;
 
if (!drm_fbdev_emulation)
return 0;
 
-   mutex_lock(_helper->dev->mode_config.mutex);
+   mutex_lock(>mode_config.mutex);
if (!fb_helper->fb || !drm_fb_helper_is_bound(fb_helper)) {
fb_helper->delayed_hotplug = true;
-   mutex_unlock(_helper->dev->mode_config.mutex);
+   mutex_unlock(>mode_config.mutex);
return 0;
}
DRM_DEBUG_KMS("\n");
 
-   max_width = fb_helper->fb->width;
-   max_height = fb_helper->fb->height;
+   drm_setup_crtcs(fb_helper, fb_helper->fb->width, fb_helper->fb->height);
 
-   drm_fb_helper_probe_connector_modes(fb_helper, max_width, max_height);
-   mutex_unlock(_helper->dev->mode_config.mutex);
+   mutex_unlock(>mode_config.mutex);
 
-   drm_modeset_lock_all(dev);
-   drm_setup_crtcs(fb_helper);
-   drm_modeset_unlock_all(dev);
drm_fb_helper_set_par(fb_helper->fbdev);
 
return 0;
-- 
2.10.2

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

[Intel-gfx] [PATCH 3/3] drm: Protect fb_helper list manipulation with a mutex

[Chris Wilson]

Though we only walk the kernel_fb_helper_list inside a panic (or single
thread debugging), we still need to protect the list manipulation on
creating/removing a framebuffer device in order to prevent list
corruption.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/drm_fb_helper.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index a19afc7eccde..2ac2f462d37b 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -49,6 +49,7 @@ MODULE_PARM_DESC(fbdev_emulation,
 "Enable legacy fbdev emulation [default=true]");
 
 static LIST_HEAD(kernel_fb_helper_list);
+static DEFINE_MUTEX(kernel_fb_helper_lock);
 
 /**
  * DOC: fbdev helpers
@@ -855,12 +856,14 @@ void drm_fb_helper_fini(struct drm_fb_helper *fb_helper)
if (!drm_fbdev_emulation)
return;
 
+   mutex_lock(_fb_helper_lock);
if (!list_empty(_helper->kernel_fb_list)) {
list_del(_helper->kernel_fb_list);
if (list_empty(_fb_helper_list)) {
unregister_sysrq_key('v', 
_drm_fb_helper_restore_op);
}
}
+   mutex_unlock(_fb_helper_lock);
 
drm_fb_helper_crtc_free(fb_helper);
 
@@ -2257,10 +2260,12 @@ int drm_fb_helper_initial_config(struct drm_fb_helper 
*fb_helper, int bpp_sel)
dev_info(dev->dev, "fb%d: %s frame buffer device\n",
 info->node, info->fix.id);
 
+   mutex_lock(_fb_helper_lock);
if (list_empty(_fb_helper_list))
register_sysrq_key('v', _drm_fb_helper_restore_op);
 
list_add(_helper->kernel_fb_list, _fb_helper_list);
+   mutex_unlock(_fb_helper_lock);
 
return 0;
 }
-- 
2.10.2

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

[Intel-gfx] [PATCH 1/3] drm: Hold mode_config.lock to prevent hotplug whilst setting up crtcs

[Chris Wilson]

The fb_helper->connector_count is modified when a new connector is
constructed following a hotplug event (e.g. DP-MST). This causes trouble
for drm_setup_crtcs() and friends that assume that fb_helper is
constant:

[ 1250.872997] BUG: KASAN: slab-out-of-bounds in drm_setup_crtcs+0x320/0xf80 at 
addr 88074cdd2608
[ 1250.873020] Write of size 40 by task kworker/u8:3/480
[ 1250.873039] CPU: 2 PID: 480 Comm: kworker/u8:3 Tainted: G U  
4.9.0-rc6+ #285
[ 1250.873043] Hardware name:  /NUC6i3SYB, BIOS 
SYSKLi35.86A.0024.2015.1027.2142 10/27/2015
[ 1250.873050] Workqueue: events_unbound async_run_entry_fn
[ 1250.873056]  88070f9d78f0 814b72aa 88074e40c5c0 
88074cdd2608
[ 1250.873067]  88070f9d7918 8124ff3c 88070f9d79b0 
88074cdd2600
[ 1250.873079]  88074e40c5c0 88070f9d79a0 812501e4 
0005
[ 1250.873090] Call Trace:
[ 1250.873099]  [] dump_stack+0x67/0x9d
[ 1250.873106]  [] kasan_object_err+0x1c/0x70
[ 1250.873113]  [] kasan_report_error+0x204/0x4f0
[ 1250.873120]  [] ? drm_dev_printk+0x140/0x140
[ 1250.873127]  [] kasan_report+0x53/0x60
[ 1250.873134]  [] ? drm_setup_crtcs+0x320/0xf80
[ 1250.873142]  [] check_memory_region+0x13e/0x1a0
[ 1250.873147]  [] memset+0x23/0x40
[ 1250.873154]  [] drm_setup_crtcs+0x320/0xf80
[ 1250.873161]  [] ? wake_up_q+0x45/0x80
[ 1250.873169]  [] ? mutex_lock_nested+0x5a0/0x5a0
[ 1250.873176]  [] drm_fb_helper_initial_config+0x206/0x7a0
[ 1250.873183]  [] ? drm_fb_helper_set_par+0x90/0x90
[ 1250.873303]  [] ? intel_fbdev_fini+0x140/0x140 [i915]
[ 1250.873387]  [] intel_fbdev_initial_config+0x22/0x40 [i915]
[ 1250.873391]  [] async_run_entry_fn+0x7f/0x270
[ 1250.873394]  [] process_one_work+0x3d0/0x960
[ 1250.873398]  [] ? process_one_work+0x33d/0x960
[ 1250.873401]  [] ? max_active_store+0xf0/0xf0
[ 1250.873406]  [] ? do_raw_spin_lock+0x10d/0x1a0
[ 1250.873413]  [] worker_thread+0x8d/0x840
[ 1250.873419]  [] ? create_worker+0x2e0/0x2e0
[ 1250.873426]  [] kthread+0x194/0x1c0
[ 1250.873432]  [] ? kthread_park+0x60/0x60
[ 1250.873438]  [] ? trace_hardirqs_on+0xd/0x10
[ 1250.873446]  [] ? kthread_park+0x60/0x60
[ 1250.873453]  [] ? kthread_park+0x60/0x60
[ 1250.873457]  [] ret_from_fork+0x27/0x40
[ 1250.873460] Object at 88074cdd2608, in cache kmalloc-32 size: 32

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98826
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/drm_fb_helper.c | 73 ++---
 1 file changed, 40 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 14547817566d..d13c85682891 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -97,6 +97,10 @@ static LIST_HEAD(kernel_fb_helper_list);
  * mmap page writes.
  */
 
+#define drm_fb_helper_for_each_connector(fbh, i__) \
+   for (({lockdep_assert_held(&(fbh)->dev->mode_config.mutex); 1;}), \
+i__ = 0; i__ < (fbh)->connector_count; i__++)
+
 /**
  * drm_fb_helper_single_add_all_connectors() - add all connectors to fbdev
  *emulation helper
@@ -130,7 +134,7 @@ int drm_fb_helper_single_add_all_connectors(struct 
drm_fb_helper *fb_helper)
mutex_unlock(>mode_config.mutex);
return 0;
 fail:
-   for (i = 0; i < fb_helper->connector_count; i++) {
+   drm_fb_helper_for_each_connector(fb_helper, i) {
struct drm_fb_helper_connector *fb_helper_connector =
fb_helper->connector_info[i];
 
@@ -565,7 +569,7 @@ static void drm_fb_helper_dpms(struct fb_info *info, int 
dpms_mode)
continue;
 
/* Walk the connectors & encoders on this fb turning them 
on/off */
-   for (j = 0; j < fb_helper->connector_count; j++) {
+   drm_fb_helper_for_each_connector(fb_helper, j) {
connector = fb_helper->connector_info[j]->connector;
connector->funcs->dpms(connector, dpms_mode);
drm_object_property_set_value(>base,
@@ -1469,7 +1473,6 @@ static int drm_fb_helper_single_fb_probe(struct 
drm_fb_helper *fb_helper,
int ret = 0;
int crtc_count = 0;
int i;
-   struct fb_info *info;
struct drm_fb_helper_surface_size sizes;
int gamma_size = 0;
 
@@ -1485,7 +1488,7 @@ static int drm_fb_helper_single_fb_probe(struct 
drm_fb_helper *fb_helper,
sizes.surface_depth = sizes.surface_bpp = preferred_bpp;
 
/* first up get a count of crtcs now in use and new min/maxes 
width/heights */
-   for (i = 0; i < fb_helper->connector_count; i++) {
+   drm_fb_helper_for_each_connector(fb_helper, i) {
struct drm_fb_helper_connector *fb_helper_conn = 
fb_helper->connector_info[i];
struct drm_cmdline_mode *cmdline_mode;
 
@@ -1572,8 +1575,6 @@ static int 

Re: [Intel-gfx] [PATCH] drm/i915: Pass dev_priv to intel_setup_outputs()

[Ville Syrjälä]

On Wed, Nov 23, 2016 at 03:48:30PM +0200, Ander Conselvan de Oliveira wrote:
> Pass dev_priv to intel_setup_outputs() and functions called by it, since
> those are all intel i915 specific functions. Also, in the majority of
> the functions dev_priv is used more often than dev. In the rare cases
> where there are a few calls back into drm core, a local dev variable was
> added.
> 
> Signed-off-by: Ander Conselvan de Oliveira 
> 
> ---
>  drivers/gpu/drm/i915/i915_drv.c  |   4 +-
>  drivers/gpu/drm/i915/i915_drv.h  |   2 +-
>  drivers/gpu/drm/i915/intel_crt.c |   7 +-
>  drivers/gpu/drm/i915/intel_ddi.c |   5 +-
>  drivers/gpu/drm/i915/intel_display.c | 120 
> ---
>  drivers/gpu/drm/i915/intel_dp.c  |   8 +--
>  drivers/gpu/drm/i915/intel_drv.h |  22 ---
>  drivers/gpu/drm/i915/intel_dsi.c |   8 +--
>  drivers/gpu/drm/i915/intel_dvo.c |   9 ++-
>  drivers/gpu/drm/i915/intel_hdmi.c|   8 +--
>  drivers/gpu/drm/i915/intel_lvds.c|   4 +-
>  drivers/gpu/drm/i915/intel_psr.c |   4 +-
>  drivers/gpu/drm/i915/intel_sdvo.c|  19 +++---
>  drivers/gpu/drm/i915/intel_tv.c  |   4 +-
>  14 files changed, 107 insertions(+), 117 deletions(-)
> 

> diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
> b/drivers/gpu/drm/i915/intel_dsi.c
> index 4e0d025..fe9a359 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -1431,15 +1431,15 @@ static void intel_dsi_add_properties(struct 
> intel_connector *connector)
>   }
>  }
>  
> -void intel_dsi_init(struct drm_device *dev)
> +void intel_dsi_init(struct drm_i915_private *dev_priv)
>  {
> + struct drm_device *dev = _priv->drm;
>   struct intel_dsi *intel_dsi;
>   struct intel_encoder *intel_encoder;
>   struct drm_encoder *encoder;
>   struct intel_connector *intel_connector;
>   struct drm_connector *connector;
>   struct drm_display_mode *scan, *fixed_mode = NULL;
> - struct drm_i915_private *dev_priv = to_i915(dev);
>   enum port port;
>   unsigned int i;
>  
> @@ -1474,8 +1474,8 @@ void intel_dsi_init(struct drm_device *dev)
>  
>   connector = _connector->base;
>  
> - drm_encoder_init(dev, encoder, _dsi_funcs, DRM_MODE_ENCODER_DSI,
> -  "DSI %c", port_name(port));
> + drm_encoder_init(_priv->drm, encoder, _dsi_funcs,
> +  DRM_MODE_ENCODER_DSI, "DSI %c", port_name(port));

Here you have introduced a local 'dev', so this hunk doesn't seem
necessary. But no biggie. Patch lgtm.

Reviewed-by: Ville Syrjälä 

-- 
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 i-g-t] tools: Add intel_dp_compliance for DisplayPort 1.2 compliance automation

[Jani Nikula]

On Tue, 22 Nov 2016, Manasi Navare  wrote:
> +
> +static void get_test_videopattern_data(void)
> +{
> + int count = 0;
> + uint16_t video_pattern_value[3];
> + char video_pattern_attribute[15];
> +
> + if (!test_data_fp)
> + fprintf(stderr, "Invalid Test data File pointer\r\n");
> +
> + rewind(test_data_fp);
> + while (!feof(test_data_fp) && count < 3)
> + fscanf(test_data_fp, "%s %u\n", video_pattern_attribute,
> +(unsigned int *)_pattern_value[count++]);
> +
> + hdisplay = video_pattern_value[0];
> + vdisplay = video_pattern_value[1];
> + bitdepth = video_pattern_value[2];
> + igt_info("Hdisplay = %d\r\n", hdisplay);
> + igt_info("Vdisplay = %d\r\n", vdisplay);
> + igt_info("BitDepth = %u\r\n", bitdepth);
> +
> +}

If you have this working now, I guess we can go with what's in [1] since
that's fairly isolated for now. It's debugfs, so we can remove it
later. In the long run, I do want this using DPCD directly though.

BR,
Jani.



[1] 
http://patchwork.freedesktop.org/patch/msgid/1479850766-32748-6-git-send-email-manasi.d.nav...@intel.com




> +
> +static int process_test_request(int test_type)
> +{
> + int mode;
> + unsigned long test_data_edid;
> + int status = 0;
> +
> + switch (test_type) {
> + case DP_TEST_LINK_VIDEO_PATTERN:
> + video_pattern_flag = true;
> + get_test_videopattern_data();
> + mode = INTEL_MODE_VIDEO_PATTERN_TEST;
> + break;
> + case DP_TEST_LINK_EDID_READ:
> + test_data_edid = get_test_edid_data();
> + mode = (test_data_edid & DP_COMPLIANCE_VIDEO_MODE_MASK) >>
> + INTEL_DP_RESOLUTION_SHIFT_MASK;
> + break;
> + default:
> + /* Unknown test type */
> + fprintf(stderr, "Invalid test request. Ignored.\r\n");
> + break;
> + }
> + status = update_display(mode, true);
> +
> + /* Return 0 on success and -1 on failure */
> + return status;
> +}
> +
> +static void dump_connectors_fd(int drmfd)
> +{
> + int i, j;
> +
> + drmModeRes *mode_resources = drmModeGetResources(drmfd);
> +
> + if (!mode_resources) {
> + igt_warn("drmModeGetResources failed: %s\n", strerror(errno));
> + return;
> + }
> +
> + igt_info("Connectors:\n");
> + igt_info("id\tencoder\tstatus\t\ttype\tsize (mm)\tmodes\n");
> + for (i = 0; i < mode_resources->count_connectors; i++) {
> + drmModeConnector *connector;
> +
> + connector = drmModeGetConnectorCurrent(drmfd,
> +
> mode_resources->connectors[i]);
> + if (!connector) {
> + igt_warn("could not get connector %i: %s\n", 
> mode_resources->connectors[i], strerror(errno));
> + continue;
> + }
> +
> + igt_info("%d\t%d\t%s\t%s\t%dx%d\t\t%d\n", 
> connector->connector_id, connector->encoder_id, 
> kmstest_connector_status_str(connector->connection), 
> kmstest_connector_type_str(connector->connector_type), connector->mmWidth, 
> connector->mmHeight, connector->count_modes);
> +
> + if (!connector->count_modes)
> + continue;
> +
> + igt_info("  modes:\n");
> + igt_info("  name refresh (Hz) hdisp hss hse htot vdisp ""vss 
> vse vtot flags type clock\n");
> + for (j = 0; j < connector->count_modes; j++) {
> + igt_info("[%d]", j);
> + kmstest_dump_mode(>modes[j]);
> + }
> +
> + drmModeFreeConnector(connector);
> + }
> + igt_info("\n");
> +
> + drmModeFreeResources(mode_resources);
> +}
> +
> +static void dump_crtcs_fd(int drmfd)
> +{
> + int i;
> + drmModeRes *mode_resources = drmModeGetResources(drmfd);
> +
> + igt_info("CRTCs:\n");
> + igt_info("id\tfb\tpos\tsize\n");
> + for (i = 0; i < mode_resources->count_crtcs; i++) {
> + drmModeCrtc *crtc;
> +
> + crtc = drmModeGetCrtc(drmfd, mode_resources->crtcs[i]);
> + if (!crtc) {
> + igt_warn("could not get crtc %i: %s\n", 
> mode_resources->crtcs[i], strerror(errno));
> + continue;
> + }
> + igt_info("%d\t%d\t(%d,%d)\t(%dx%d)\n", crtc->crtc_id, 
> crtc->buffer_id, crtc->x, crtc->y, crtc->width, crtc->height);
> + kmstest_dump_mode(>mode);
> +
> + drmModeFreeCrtc(crtc);
> + }
> + igt_info("\n");
> +
> + drmModeFreeResources(mode_resources);
> +}
> +
> +static void dump_info(void)
> +{
> + dump_connectors_fd(drm_fd);
> + dump_crtcs_fd(drm_fd);
> +}
> +
> +static void connector_find_preferred_mode(uint32_t connector_id,
> +   unsigned long crtc_idx_mask,
> +   

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Add support for DP Video pattern compliance tests

[Jani Nikula]

On Wed, 23 Nov 2016, Ville Syrjälä  wrote:
> On Wed, Nov 23, 2016 at 03:37:24PM +0200, Jani Nikula wrote:
>> On Tue, 22 Nov 2016, Manasi Navare  wrote:
>> > The intel_dp_autotest_video_pattern() function gets invoked through the
>> > compliance test handler on a HPD short pulse if the test type is
>> > set to DP_TEST_VIDEO_PATTERN. This performs the DPCD registers
>> > reads to read the requested test pattern, video pattern resolution,
>> > frame rate and bits per color value. The results of this analysis
>> > are handed off to userspace so that the userspace app can set the
>> > video pattern mode appropriately for the test result/response.
>> >
>> > The compliance_test_active flag is set at the end of the individual
>> > test handling functions. This is so that the kernel-side operations
>> > can be completed without the risk of interruption from the userspace
>> > app that is polling on that flag.
>> 
>> I've brought this up before, but I think for this stuff the way to go is
>> to have the userspace read the DPCD directly. We have the dev node for
>> it.
>> 
>> With the approach in this patch, we'll just end up reading a bunch of
>> stuff from DPCD in kernel, doing error handling for that, decoding and
>> sanity checking the values, putting them in debugfs for the userspace to
>> read, having userspace code read debugfs, doing error handling for that,
>> decoding and sanity checking the data, finally doing something based on
>> the data.
>> 
>> You'll also get a *much* faster turnaround for getting your userspace
>> code done than getting all of this in kernel first, then tweaking your
>> userspace, having to update both of those in lockstep, etc. When this is
>> based on reading DPCD directly, you can just add new stuff quickly in
>> userspace, with no kernel dependency.
>> 
>> The easiest way would be to have an indication in debugfs for userspace
>> that there's something interesting in DPCD. Just a simple thing.
>
> Or just have the kernel fire off an uevent...

I know, I know, I had that written in my mail already, but swallowed it
not to add another dependency on another new UABI... we can do that
later.

BR,
Jani.


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

Re: [Intel-gfx] [PATCH i-g-t 3/4 v6] tests/drv_module_reload: Convert sh script to C version.

[Chris Wilson]

On Wed, Nov 23, 2016 at 02:35:11PM +0200, Marius Vlad wrote:
> v5:
> - reword gem_info to gem_sanitychecks (Chris Wilson)
> - remove subgroups/subtests for gem_exec_store and gem_sanitycheck
> (Chris Wilson)
> 
> v4:
> - adjust test to make use of lib/igt_kmod
> - replaced SW_FINISH with SET_CACHEING (Chris Wilson)
> 
> v3:
> - fix passing boolean value as flags to igt_kmod_unload().
> 
> v2:
> - embedded gem_alive and gem_exec_store into test (Chris Wilson)
> - int main() to igt_main (Chris Wilson)
> - moved tests/gem_alive -> tools/gem_info (Chris Wilson)
> - added to intel-ci/fast-feedback.testlist (Petri Latvala)
> - added hda_dynamic_debug() (Petri Latvala)
> - renamed from tests/drv_module_reload_basic to tests/drv_module_reload
> (all subtests are basic and have been added to fast-feedback.testlist)
> 
> Signed-off-by: Marius Vlad 
> ---
>  tests/Makefile.am |   1 -
>  tests/Makefile.sources|   2 +-
>  tests/drv_module_reload.c | 332 
> ++
>  tests/drv_module_reload_basic | 111 
>  tests/gem_alive.c |  35 
>  tests/intel-ci/fast-feedback.testlist |   4 +-
>  tools/Makefile.sources|   1 +
>  tools/intel_gem_info.c|  35 
>  8 files changed, 372 insertions(+), 149 deletions(-)
>  create mode 100644 tests/drv_module_reload.c
>  delete mode 100755 tests/drv_module_reload_basic
>  delete mode 100644 tests/gem_alive.c
>  create mode 100644 tools/intel_gem_info.c
> 
> diff --git a/tests/Makefile.am b/tests/Makefile.am
> index a408126..14a41ae 100644
> --- a/tests/Makefile.am
> +++ b/tests/Makefile.am
> @@ -26,7 +26,6 @@ noinst_PROGRAMS = \
>   $(NULL)
>  
>  pkglibexec_PROGRAMS = \
> - gem_alive \
>   gem_stress \
>   $(TESTS_progs) \
>   $(TESTS_progs_M) \
> diff --git a/tests/Makefile.sources b/tests/Makefile.sources
> index 65e0792..2d6ed8d 100644
> --- a/tests/Makefile.sources
> +++ b/tests/Makefile.sources
> @@ -214,6 +214,7 @@ TESTS_progs = \
>   kms_pwrite_crc \
>   kms_sink_crc_basic \
>   prime_udl \
> + drv_module_reload \
>   $(NULL)
>  
>  # IMPORTANT: The ZZ_ tests need to be run last!
> @@ -224,7 +225,6 @@ TESTS_scripts_M = \
>  TESTS_scripts = \
>   debugfs_emon_crash \
>   drv_debugfs_reader \
> - drv_module_reload_basic \
>   kms_sysfs_edid_timing \
>   sysfs_l3_parity \
>   test_rte_check \
> diff --git a/tests/drv_module_reload.c b/tests/drv_module_reload.c
> new file mode 100644
> index 000..31ec2ec
> --- /dev/null
> +++ b/tests/drv_module_reload.c
> @@ -0,0 +1,332 @@
> +/*
> + * 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
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> DEALINGS
> + * IN THE SOFTWARE.
> + */
> +#include "igt.h"
> +#include "igt_debugfs.h"
> +#include "igt_aux.h"
> +#include "igt_kmod.h"
> +#include "igt_sysfs.h"
> +#include "igt_core.h"
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +
> +#define LOCAL_I915_EXEC_BSD_SHIFT  (13)
> +#define LOCAL_I915_EXEC_BSD_MASK   (3 << LOCAL_I915_EXEC_BSD_SHIFT)
> +
> +#define ENGINE_MASK  (I915_EXEC_RING_MASK | LOCAL_I915_EXEC_BSD_MASK)
> +
> +static void store_dword(int fd, unsigned ring)
> +{
> + const int gen = intel_gen(intel_get_drm_devid(fd));
> + struct drm_i915_gem_exec_object2 obj[2];
> + struct drm_i915_gem_relocation_entry reloc;
> + struct drm_i915_gem_execbuffer2 execbuf;
> + uint32_t batch[16];
> + int i;
> +
> + if (!gem_has_ring(fd, ring))
> + return;
> +
> + if (gen == 6 && (ring & ~(3<<13)) == I915_EXEC_BSD)
> + return;
> +
> + intel_detect_and_clear_missed_interrupts(fd);
> + memset(, 0, sizeof(execbuf));
> + execbuf.buffers_ptr = (uintptr_t)obj;
> + 

Re: [Intel-gfx] [PATCH i-g-t 1/4 v6] lib/{igt_sysfs, igt_aux}: Make available to other users kick_fbcon() (unbind_fbcon()), and added helpers to lib/igt_aux, lib/igt_kmod.

[Chris Wilson]

On Wed, Nov 23, 2016 at 02:35:09PM +0200, Marius Vlad wrote:
> +static void
> +igt_show_stat(proc_t *info, const char *fn)
> +{
> + static int display = 0;
> +
> + if (!display) {
> + igt_info("%20.20s%11.11s%21.21s%11.11s%10.10s%22.22s%31.31s\n",
> + "COMM", "PID", "Type", "UID", "GID", "Size", 
> "Filename");
> + display++;
> + }

This is called by an exported igt_lsof(). Only showing the header for
the first caller is a nuisance.

> +
> + __igt_show_stat(&(struct pinfo) {.pid = info->tid,
> +  .comm = info->cmd, fn });
> +}
> +

> +int
> +igt_i915_driver_unload(void)
> +{
> + /* unbind vt */
> + kick_fbcon(false);
> +
> + if (igt_kmod_is_loaded("snd_hda_intel")) {
> + igt_pkill(SIGTERM, "alsactl");
> +
> + /* unbind snd_hda_intel */
> + kick_snd_hda_intel();
> +
> + if (igt_kmod_unload("snd_hda_intel", 0)) {
> + igt_info("Could not unload snd_hda_intel\n");
> + igt_kmod_list_loaded();
> + igt_lsof("/dev/snd");
> + return IGT_EXIT_FAILURE;
> + }
> + }
> +
> + /* gen5 */
> + if (igt_kmod_is_loaded("intel_ips")) {
> + igt_kmod_unload("intel_ips", 0);
> + }
> +
> + if (igt_kmod_is_loaded("i915")) {
> + if (igt_kmod_unload("i915", 0)) {
> + igt_info("Could not unload i915\n");
> + igt_kmod_list_loaded();
> + return IGT_EXIT_SKIP;
> + } else {
> + igt_info("i915.ko has been unloaded!\n");
> + }
> + }
> +
> + if (igt_kmod_is_loaded("intel-gtt")) {
> + igt_kmod_unload("intel-gtt", 0);
> + }
> +
> + igt_kmod_unload("drm_kms_helper", 0);
> + igt_kmod_unload("drm", 0);
> +
> + if (igt_kmod_is_loaded("i915")) {
> + igt_info("WARNING: i915.ko still loaded!\n");

igt_warn() perchance?

> + return IGT_EXIT_FAILURE;
> + } else {
> + igt_info("module successfully unloaded\n");
> + }
> +
> +
> + return IGT_EXIT_SUCCESS;
> +}

-- 
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] [PATCH] drm/i915: Pass dev_priv to intel_setup_outputs()

[Ander Conselvan de Oliveira]

Pass dev_priv to intel_setup_outputs() and functions called by it, since
those are all intel i915 specific functions. Also, in the majority of
the functions dev_priv is used more often than dev. In the rare cases
where there are a few calls back into drm core, a local dev variable was
added.

Signed-off-by: Ander Conselvan de Oliveira 

---
 drivers/gpu/drm/i915/i915_drv.c  |   4 +-
 drivers/gpu/drm/i915/i915_drv.h  |   2 +-
 drivers/gpu/drm/i915/intel_crt.c |   7 +-
 drivers/gpu/drm/i915/intel_ddi.c |   5 +-
 drivers/gpu/drm/i915/intel_display.c | 120 ---
 drivers/gpu/drm/i915/intel_dp.c  |   8 +--
 drivers/gpu/drm/i915/intel_drv.h |  22 ---
 drivers/gpu/drm/i915/intel_dsi.c |   8 +--
 drivers/gpu/drm/i915/intel_dvo.c |   9 ++-
 drivers/gpu/drm/i915/intel_hdmi.c|   8 +--
 drivers/gpu/drm/i915/intel_lvds.c|   4 +-
 drivers/gpu/drm/i915/intel_psr.c |   4 +-
 drivers/gpu/drm/i915/intel_sdvo.c|  19 +++---
 drivers/gpu/drm/i915/intel_tv.c  |   4 +-
 14 files changed, 107 insertions(+), 117 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 445fec9..5917af1 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1571,7 +1571,7 @@ static int i915_drm_resume(struct drm_device *dev)
intel_pps_unlock_regs_wa(dev_priv);
intel_opregion_setup(dev_priv);
 
-   intel_init_pch_refclk(dev);
+   intel_init_pch_refclk(dev_priv);
drm_mode_config_reset(dev);
 
/*
@@ -2408,7 +2408,7 @@ static int intel_runtime_resume(struct device *kdev)
intel_guc_resume(dev);
 
if (IS_GEN6(dev_priv))
-   intel_init_pch_refclk(dev);
+   intel_init_pch_refclk(dev_priv);
 
if (IS_BROXTON(dev_priv)) {
bxt_disable_dc9(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index be67aee..c0d0a0d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3487,7 +3487,7 @@ extern void intel_display_resume(struct drm_device *dev);
 extern void i915_redisable_vga(struct drm_i915_private *dev_priv);
 extern void i915_redisable_vga_power_on(struct drm_i915_private *dev_priv);
 extern bool ironlake_set_drps(struct drm_i915_private *dev_priv, u8 val);
-extern void intel_init_pch_refclk(struct drm_device *dev);
+extern void intel_init_pch_refclk(struct drm_i915_private *dev_priv);
 extern void intel_set_rps(struct drm_i915_private *dev_priv, u8 val);
 extern void intel_set_memory_cxsr(struct drm_i915_private *dev_priv,
  bool enable);
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 86ecec5..385e29a 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -836,12 +836,11 @@ static const struct drm_encoder_funcs intel_crt_enc_funcs 
= {
.destroy = intel_encoder_destroy,
 };
 
-void intel_crt_init(struct drm_device *dev)
+void intel_crt_init(struct drm_i915_private *dev_priv)
 {
struct drm_connector *connector;
struct intel_crt *crt;
struct intel_connector *intel_connector;
-   struct drm_i915_private *dev_priv = to_i915(dev);
i915_reg_t adpa_reg;
u32 adpa;
 
@@ -881,10 +880,10 @@ void intel_crt_init(struct drm_device *dev)
 
connector = _connector->base;
crt->connector = intel_connector;
-   drm_connector_init(dev, _connector->base,
+   drm_connector_init(_priv->drm, _connector->base,
   _crt_connector_funcs, DRM_MODE_CONNECTOR_VGA);
 
-   drm_encoder_init(dev, >base.base, _crt_enc_funcs,
+   drm_encoder_init(_priv->drm, >base.base, _crt_enc_funcs,
 DRM_MODE_ENCODER_DAC, "CRT");
 
intel_connector_attach_encoder(intel_connector, >base);
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 10ec9d4..a45dc37 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2154,9 +2154,8 @@ intel_ddi_get_link_dpll(struct intel_dp *intel_dp, int 
clock)
return pll;
 }
 
-void intel_ddi_init(struct drm_device *dev, enum port port)
+void intel_ddi_init(struct drm_i915_private *dev_priv, enum port port)
 {
-   struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_digital_port *intel_dig_port;
struct intel_encoder *intel_encoder;
struct drm_encoder *encoder;
@@ -2218,7 +2217,7 @@ void intel_ddi_init(struct drm_device *dev, enum port 
port)
intel_encoder = _dig_port->base;
encoder = _encoder->base;
 
-   drm_encoder_init(dev, encoder, _ddi_funcs,
+   drm_encoder_init(_priv->drm, encoder, _ddi_funcs,
 DRM_MODE_ENCODER_TMDS, "DDI %c", port_name(port));
 
intel_encoder->compute_config = intel_ddi_compute_config;

[Intel-gfx] [PATCH] drm/i915: Move number of scalers initialization to runtime init

[Nabendu Maiti]

In future patches, we require greater flexibility in describing
the number of scalers available on each CRTC. To ease that transition
we move the current assignment to intel_device_info. Scaler structure
initialisation is done if scaler is available on the CRTC.

Gen9 check is not required as depending on numbers of scalers we
initialize scalers or return without doing anything in skl_init_scalers.

Signed-off-by: Nabendu Maiti 
---
 drivers/gpu/drm/i915/i915_debugfs.c  |  2 +-
 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 drivers/gpu/drm/i915/intel_device_info.c |  3 +++
 drivers/gpu/drm/i915/intel_display.c | 18 --
 4 files changed, 13 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index b7f42c4..8349abe 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3080,7 +3080,7 @@ static void intel_scaler_info(struct seq_file *m, struct 
intel_crtc *intel_crtc)
   pipe_config->scaler_state.scaler_users,
   pipe_config->scaler_state.scaler_id);
 
-   for (i = 0; i < SKL_NUM_SCALERS; i++) {
+   for (i = 0; i < num_scalers; i++) {
struct intel_scaler *sc =
_config->scaler_state.scalers[i];
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index be67aee..6eed9c2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -731,6 +731,7 @@ struct intel_device_info {
u16 device_id;
u8 num_pipes;
u8 num_sprites[I915_MAX_PIPES];
+   u8 num_scalers[I915_MAX_PIPES];
u8 gen;
u16 gen_mask;
u8 ring_mask; /* Rings supported by the HW */
diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index 185e3bb..ef26fa8 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -282,6 +282,9 @@ void intel_device_info_runtime_init(struct drm_i915_private 
*dev_priv)
info->num_sprites[PIPE_A] = 2;
info->num_sprites[PIPE_B] = 2;
info->num_sprites[PIPE_C] = 1;
+   info->num_scalers[PIPE_A] = 2;
+   info->num_scalers[PIPE_B] = 2;
+   info->num_scalers[PIPE_C] = 1;
} else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
for_each_pipe(dev_priv, pipe)
info->num_sprites[pipe] = 2;
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index bd2c99e..331131d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15237,6 +15237,11 @@ static void skl_init_scalers(struct drm_i915_private 
*dev_priv,
_state->scaler_state;
int i;
 
+   crtc->num_scalers = dev_priv->info.num_scalers[crtc->pipe];
+
+   if (!crtc->num_scalers)
+   return;
+
for (i = 0; i < crtc->num_scalers; i++) {
struct intel_scaler *scaler = _state->scalers[i];
 
@@ -15268,16 +15273,6 @@ static int intel_crtc_init(struct drm_i915_private 
*dev_priv, enum pipe pipe)
intel_crtc->base.state = _state->base;
crtc_state->base.crtc = _crtc->base;
 
-   /* initialize shared scalers */
-   if (INTEL_GEN(dev_priv) >= 9) {
-   if (pipe == PIPE_C)
-   intel_crtc->num_scalers = 1;
-   else
-   intel_crtc->num_scalers = SKL_NUM_SCALERS;
-
-   skl_init_scalers(dev_priv, intel_crtc, crtc_state);
-   }
-
primary = intel_primary_plane_create(dev_priv, pipe);
if (IS_ERR(primary)) {
ret = PTR_ERR(primary);
@@ -15316,6 +15311,9 @@ static int intel_crtc_init(struct drm_i915_private 
*dev_priv, enum pipe pipe)
 
intel_crtc->wm.cxsr_allowed = true;
 
+   /* initialize shared scalers */
+   skl_init_scalers(dev_priv, intel_crtc, crtc_state);
+
BUG_ON(pipe >= ARRAY_SIZE(dev_priv->plane_to_crtc_mapping) ||
   dev_priv->plane_to_crtc_mapping[intel_crtc->plane] != NULL);
dev_priv->plane_to_crtc_mapping[intel_crtc->plane] = intel_crtc;
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Add support for DP Video pattern compliance tests

[Ville Syrjälä]

On Wed, Nov 23, 2016 at 03:37:24PM +0200, Jani Nikula wrote:
> On Tue, 22 Nov 2016, Manasi Navare  wrote:
> > The intel_dp_autotest_video_pattern() function gets invoked through the
> > compliance test handler on a HPD short pulse if the test type is
> > set to DP_TEST_VIDEO_PATTERN. This performs the DPCD registers
> > reads to read the requested test pattern, video pattern resolution,
> > frame rate and bits per color value. The results of this analysis
> > are handed off to userspace so that the userspace app can set the
> > video pattern mode appropriately for the test result/response.
> >
> > The compliance_test_active flag is set at the end of the individual
> > test handling functions. This is so that the kernel-side operations
> > can be completed without the risk of interruption from the userspace
> > app that is polling on that flag.
> 
> I've brought this up before, but I think for this stuff the way to go is
> to have the userspace read the DPCD directly. We have the dev node for
> it.
> 
> With the approach in this patch, we'll just end up reading a bunch of
> stuff from DPCD in kernel, doing error handling for that, decoding and
> sanity checking the values, putting them in debugfs for the userspace to
> read, having userspace code read debugfs, doing error handling for that,
> decoding and sanity checking the data, finally doing something based on
> the data.
> 
> You'll also get a *much* faster turnaround for getting your userspace
> code done than getting all of this in kernel first, then tweaking your
> userspace, having to update both of those in lockstep, etc. When this is
> based on reading DPCD directly, you can just add new stuff quickly in
> userspace, with no kernel dependency.
> 
> The easiest way would be to have an indication in debugfs for userspace
> that there's something interesting in DPCD. Just a simple thing.

Or just have the kernel fire off an uevent...

-- 
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 5/5] drm/i915: Add support for DP Video pattern compliance tests

[Jani Nikula]

On Tue, 22 Nov 2016, Manasi Navare  wrote:
> The intel_dp_autotest_video_pattern() function gets invoked through the
> compliance test handler on a HPD short pulse if the test type is
> set to DP_TEST_VIDEO_PATTERN. This performs the DPCD registers
> reads to read the requested test pattern, video pattern resolution,
> frame rate and bits per color value. The results of this analysis
> are handed off to userspace so that the userspace app can set the
> video pattern mode appropriately for the test result/response.
>
> The compliance_test_active flag is set at the end of the individual
> test handling functions. This is so that the kernel-side operations
> can be completed without the risk of interruption from the userspace
> app that is polling on that flag.

I've brought this up before, but I think for this stuff the way to go is
to have the userspace read the DPCD directly. We have the dev node for
it.

With the approach in this patch, we'll just end up reading a bunch of
stuff from DPCD in kernel, doing error handling for that, decoding and
sanity checking the values, putting them in debugfs for the userspace to
read, having userspace code read debugfs, doing error handling for that,
decoding and sanity checking the data, finally doing something based on
the data.

You'll also get a *much* faster turnaround for getting your userspace
code done than getting all of this in kernel first, then tweaking your
userspace, having to update both of those in lockstep, etc. When this is
based on reading DPCD directly, you can just add new stuff quickly in
userspace, with no kernel dependency.

The easiest way would be to have an indication in debugfs for userspace
that there's something interesting in DPCD. Just a simple thing.

BR,
Jani.


>
> Signed-off-by: Manasi Navare 
> Cc: Jani Nikula 
> Cc: Daniel Vetter 
> Cc: Ville Syrjala 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 14 +++-
>  drivers/gpu/drm/i915/intel_dp.c | 68 
> +
>  drivers/gpu/drm/i915/intel_drv.h|  9 +
>  3 files changed, 90 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 3799a12..b048a0e 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -4545,7 +4545,19 @@ static int i915_displayport_test_data_show(struct 
> seq_file *m, void *data)
>   if (connector->status == connector_status_connected &&
>   connector->encoder != NULL) {
>   intel_dp = enc_to_intel_dp(connector->encoder);
> - seq_printf(m, "%lx", intel_dp->compliance_test_data);
> + if (intel_dp->compliance_test_type ==
> + DP_TEST_LINK_EDID_READ)
> + seq_printf(m, "%lx",
> +intel_dp->compliance_test_data);
> + else if (intel_dp->compliance_test_type ==
> +  DP_TEST_LINK_VIDEO_PATTERN) {
> + seq_printf(m, "hdisplay: %d\n",
> +intel_dp->test_data.hdisplay);
> + seq_printf(m, "vdisplay: %d\n",
> +intel_dp->test_data.vdisplay);
> + seq_printf(m, "bpc: %u\n",
> +intel_dp->test_data.bpc);
> + }
>   } else
>   seq_puts(m, "0");
>   }
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index f93e130..784f86e 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -28,8 +28,10 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -3868,7 +3870,73 @@ static uint8_t intel_dp_autotest_link_training(struct 
> intel_dp *intel_dp)
>  static uint8_t intel_dp_autotest_video_pattern(struct intel_dp *intel_dp)
>  {
>   uint8_t test_result = DP_TEST_NAK;
> + uint8_t test_pattern;
> + uint16_t test_misc;
> + __be16 h_width, v_height;
> + int status = 0;
> +
> + /* Read the TEST_PATTERN (DP CTS 3.1.5) */
> + status = drm_dp_dpcd_read(_dp->aux, DP_TEST_PATTERN,
> +   _pattern, 1);
> + if (status <= 0) {
> + DRM_DEBUG_KMS("Could not read test pattern from "
> +   "reference sink\n");
> + return 0;
> + }
> + if (test_pattern != DP_COLOR_RAMP)
> + return test_result;
> + intel_dp->test_data.video_pattern = test_pattern;
> +
> + status = drm_dp_dpcd_read(_dp->aux, DP_TEST_H_WIDTH,
> +   _width, 2);
> + if 

Re: [Intel-gfx] [PATCH i-g-t 2/4 v6] lib/igt_gvt: Make use of libkmod helpers and fix reading gvt parameter.

[Chris Wilson]

On Wed, Nov 23, 2016 at 02:35:10PM +0200, Marius Vlad wrote:
> v2:
> - use igt_sysfs_get_boolean() to get gvt status (Chris Wilson)
> - do not hard-fail when i915 module could not be loaded/unloaded (Chris
> Wilson)
> 
> Signed-off-by: Marius Vlad 
> ---
>  lib/igt_gvt.c | 37 ++---
>  tests/gvt_basic.c |  2 +-
>  2 files changed, 19 insertions(+), 20 deletions(-)
> 
> diff --git a/lib/igt_gvt.c b/lib/igt_gvt.c
> index 8bbf9bd..4ab7433 100644
> --- a/lib/igt_gvt.c
> +++ b/lib/igt_gvt.c
> @@ -24,35 +24,30 @@
>  #include "igt.h"
>  #include "igt_gvt.h"
>  #include "igt_sysfs.h"
> +#include "igt_kmod.h"
>  
> +#include 
>  #include 
>  #include 
>  #include 
>  
>  static bool is_gvt_enabled(void)
>  {
> - FILE *file;
> - int value;
>   bool enabled = false;
> + int dir, fd;
>  
> - file = fopen("/sys/module/i915/parameters/enable_gvt", "r");
> - if (!file)
> + fd = __drm_open_driver(DRIVER_INTEL);
> + dir = igt_sysfs_open_parameters(fd);
> + if (dir < 0)
>   return false;
>  
> - if (fscanf(file, "%d", ) == 1)
> - enabled = value;
> - fclose(file);
> + enabled = igt_sysfs_get_boolean(dir, "enable_gvt");
>  
> - errno = 0;
> - return enabled;
> -}
> + close(dir);
> + close(fd);
>  
> -static void unload_i915(void)
> -{
> - kick_fbcon(false);
> - /* pkill alsact */
> + return enabled;
>  
> - igt_ignore_warn(system("/sbin/modprobe -s -r i915"));
>  }
>  
>  bool igt_gvt_load_module(void)
> @@ -60,8 +55,11 @@ bool igt_gvt_load_module(void)
>   if (is_gvt_enabled())
>   return true;
>  
> - unload_i915();
> - igt_ignore_warn(system("/sbin/modprobe -s i915 enable_gvt=1"));
> + if (igt_i915_driver_unload())
> + return false;
> +
> + if (igt_i915_driver_load("enable_gvt=1"))
> + return false;
>  
>   return is_gvt_enabled();
>  }
> @@ -71,8 +69,9 @@ void igt_gvt_unload_module(void)
>   if (!is_gvt_enabled())
>   return;
>  
> - unload_i915();
> - igt_ignore_warn(system("/sbin/modprobe -s i915 enable_gvt=0"));
> + igt_i915_driver_unload();
> +
> + igt_i915_driver_load(NULL);
>  
>   igt_assert(!is_gvt_enabled());
>  }
> diff --git a/tests/gvt_basic.c b/tests/gvt_basic.c
> index 48b853a..4e909a5 100644
> --- a/tests/gvt_basic.c
> +++ b/tests/gvt_basic.c
> @@ -32,7 +32,7 @@ igt_main
>  
>   igt_fixture {
>   igt_require(igt_gvt_load_module());
> - fd = drm_open_driver(DRIVER_INTEL);
> + fd = __drm_open_driver(DRIVER_INTEL);

I couldn't work out why this needed to switch to the non-checking, bare
call to open_driver().
-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 4/5] drm: Add definitions for DP compliance Video pattern tests

[Jani Nikula]

On Tue, 22 Nov 2016, Manasi Navare  wrote:
> Cc: dri-de...@lists.freedesktop.org
> Cc: Jani Nikula 
> Cc: Daniel Vetter 
> Cc: Ville Syrjala 
> Signed-off-by: Manasi Navare 
> ---
>  include/drm/drm_dp_helper.h | 16 +++-
>  1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 55bbeb0..f2c04ec 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -415,7 +415,21 @@
>  
>  #define DP_TEST_LANE_COUNT   0x220
>  
> -#define DP_TEST_PATTERN  0x221
> +#define DP_TEST_PATTERN  0x221

Unnecessary indentation change. Please observe the code around you. It
may not have the best indentation style, but stick with what's there
for all the other DPCD address definitions.

> +#define DP_COLOR_RAMP(1 << 0)

See how all the other address *content* definitions have a space between
"#" and "define". I'm not saying I like it, but it's uniform in the
file.

While at it, why not add all of the defines for TEST_PATTERN. And
observe how they are not bit patterns, so (1 << 0) should be just 1.

DP_NO_TEST_PATTERN
DP_COLOR_RAMPS
DP_BLACK_AND_WHITE_VERTICAL_LINES
DP_COLOR_SQUARE

> +#define DP_TEST_H_WIDTH  0x22E

Note that across the file, almost all addrses defines have a blank line
between them, to separate content definitions from other addresses.

> +#define DP_TEST_V_HEIGHT 0x230

I guess I'd do

#define DP_TEST_V_HEIGHT_HI 0x230
#define DP_TEST_V_HEIGHT_LO 0x231

You don't actually have to *use* both definitions if you can write both
in one go, but this saves the trouble of checking the DP spec when it's
documented as #defines here.

> +#define DP_TEST_MISC 0x232
> +#define DP_VIDEO_PATTERN_RGB_FORMAT  0

The convention is to shift the 0 too so it's obvious where it
fits. _MASK goes before the values. Please add all the values.

> +#define DP_TEST_COLOR_FORMAT_MASK0x6
> +#define DP_TEST_DYNAMIC_RANGE_MASK   (1 << 3)

And the values?

> +#define DP_VIDEO_PATTERN_VESA0
> +#define DP_TEST_BIT_DEPTH_MASK   0x00E0
> +#define DP_TEST_BIT_DEPTH_6  0

> +#define DP_TEST_BIT_DEPTH_8  1

Just add all of the values at once.

> +#define DP_TEST_MISC_BIT_1   1
> +#define DP_TEST_MISC_BIT_3   3
> +#define DP_TEST_MISC_BIT_5   5
>  
>  #define DP_TEST_CRC_R_CR 0x240
>  #define DP_TEST_CRC_G_Y  0x242

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

Re: [Intel-gfx] [PATCH 3/5] Add support for forcing 6 bpc on DP pipes.

[Jani Nikula]

On Tue, 22 Nov 2016, Manasi Navare  wrote:
> From: Jim Bride 
>
> For DP compliance we need to be able to control the output color
> type for the pipe associated with the DP port. When a specific DP
> compliance test is requested with specific BPC value, we read the BPC
> value from the DPCD register and store it in the intel_dp structure.
> If this BPC value in intel_dp structure  has a non-zero value
> and we're on a display port connector, then we use the value to
> calculate the bpp for the pipe.  For cases where we are
> not on DP or there has not been an overridden value then we behave
> as normal.
>
> Signed-off-by: Jim Bride 
> Signed-off-by: Manasi Navare 
> Cc: Jani Nikula 
> Cc: Daniel Vetter 
> Cc: Ville Syrjala 
> ---
>  drivers/gpu/drm/i915/intel_display.c |  4 +++-
>  drivers/gpu/drm/i915/intel_dp.c  | 10 ++
>  drivers/gpu/drm/i915/intel_dp_mst.c  | 11 +--
>  drivers/gpu/drm/i915/intel_drv.h |  1 +
>  4 files changed, 23 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index b7a7ed8..bb1cca2 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12694,11 +12694,13 @@ static void 
> intel_modeset_update_connector_atomic_state(struct drm_device *dev)
>  
>   /* Clamp display bpp to EDID value */
>   for_each_connector_in_state(state, connector, connector_state, i) {
> +

Unrelated change, and one we don't want.

>   if (connector_state->crtc != >base)
>   continue;
>  
>   connected_sink_compute_bpp(to_intel_connector(connector),
> -pipe_config);
> +pipe_config);
> +

Unrelated change, and one we don't want.

>   }
>  
>   return bpp;
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 6693918..f93e130 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1549,6 +1549,13 @@ static int intel_dp_compute_bpp(struct intel_dp 
> *intel_dp,
>   if (bpc > 0)
>   bpp = min(bpp, 3*bpc);
>  
> + /* For DP Compliance we override the computed bpp for the pipe */
> + if (intel_dp->compliance_force_bpc != 0) {

You don't actually *set* compliance_force_bpc in this patch, making all
of this a complicated nop. We don't want this kind of changes, because
if this regresses, it'll regress in the patch actually *using* the code,
i.e. the patch setting compliance_force_bpc, not this one.

The rationale is the same as for adding unused functions as prep
patches.

> + pipe_config->pipe_bpp = intel_dp->compliance_force_bpc*3;

How about making that compliance_force_bpp and setting it to * 3
directly in one place instead of sprinkling the * 3 all over the place?

> + DRM_DEBUG_KMS("Setting pipe_bpp to %d\n",
> +   pipe_config->pipe_bpp);
> + }
> +
>   return bpp;
>  }
>  
> @@ -1629,6 +1636,7 @@ static int intel_dp_compute_bpp(struct intel_dp 
> *intel_dp,
>   /* Walk through all bpp values. Luckily they're all nicely spaced with 2
>* bpc in between. */
>   bpp = intel_dp_compute_bpp(intel_dp, pipe_config);
> +

Unrelated change. Please pay attention to these.

>   if (is_edp(intel_dp)) {
>  
>   /* Get bpp from vbt only for panels that dont have bpp in edid 
> */
> @@ -4109,6 +4117,7 @@ static void intel_dp_handle_test_request(struct 
> intel_dp *intel_dp)
>   intel_dp->compliance_test_data = 0;
>   intel_dp->compliance_test_lane_count = 0;
>   intel_dp->compliance_test_link_rate = 0;
> + intel_dp->compliance_force_bpc = 0;

Again, benefits from having a sub struct.

>  
>   /*
>* Now read the DPCD to see if it's actually running
> @@ -4434,6 +4443,7 @@ static bool intel_digital_port_connected(struct 
> drm_i915_private *dev_priv,
>   intel_dp->compliance_test_active = 0;
>   intel_dp->compliance_test_type = 0;
>   intel_dp->compliance_test_data = 0;
> + intel_dp->compliance_force_bpc = 0;
>   intel_dp->compliance_test_lane_count = 0;
>   intel_dp->compliance_test_link_rate = 0;
>  
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index b029d10..940f173 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -45,6 +45,14 @@ static bool intel_dp_mst_compute_config(struct 
> intel_encoder *encoder,
>  
>   pipe_config->has_pch_encoder = false;
>   bpp = 24;
> + /* For DP Compliance we need to ensurethat we can override
> +  * the computed bpp for the 

[Intel-gfx] [PATCH i-g-t 1/2] lib: Check format of framebuffer before SetPlane

[Tomeu Vizoso]

Avoid setting a framebuffer in a format that the plane doesn't support,
so we have better debug output in IGT and we don't have to dig into
dmesg files to find out what's going on.

I found this issue when kms_plane_scaling tried to use a cursor plane as
a regular one in a Skylake machine with just one overlay.

Signed-off-by: Tomeu Vizoso 
---
 lib/igt_kms.c | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 989704e14803..3234fa1bbdc4 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -1670,6 +1670,14 @@ static uint32_t igt_plane_get_fb_id(igt_plane_t *plane)
return 0;
 }
 
+static uint32_t igt_plane_get_fb_format(igt_plane_t *plane)
+{
+   if (plane->fb)
+   return plane->fb->drm_format;
+   else
+   return 0;
+}
+
 static uint32_t igt_plane_get_fb_gem_handle(igt_plane_t *plane)
 {
if (plane->fb)
@@ -1678,6 +1686,28 @@ static uint32_t igt_plane_get_fb_gem_handle(igt_plane_t 
*plane)
return 0;
 }
 
+static bool igt_plane_supports_format(igt_plane_t *plane, uint32_t format)
+{
+   int i;
+
+   for (i = 0; i < plane->drm_plane->count_formats; i++) {
+   if (format == plane->drm_plane->formats[i])
+   return true;
+   }
+
+   igt_debug("Plane %d in pipe %s doesn't support format %s.\n",
+ plane->index,
+ kmstest_pipe_name(plane->pipe->pipe),
+ igt_format_str(format));
+
+   igt_debug("Formats supported are:");
+   for (i = 0; i < plane->drm_plane->count_formats; i++)
+   igt_debug(" %s", igt_format_str(plane->drm_plane->formats[i]));
+   igt_debug(".\n");
+
+   return false;
+}
+
 #define CHECK_RETURN(r, fail) {\
if (r && !fail) \
return r;   \
@@ -1772,6 +1802,7 @@ static int igt_drm_plane_commit(igt_plane_t *plane,
int32_t crtc_y;
uint32_t crtc_w;
uint32_t crtc_h;
+   uint32_t format;
 
igt_assert(plane->drm_plane);
 
@@ -1821,6 +1852,10 @@ static int igt_drm_plane_commit(igt_plane_t *plane,
src_x >> 16, src_y >> 16, src_w >> 16, src_h >> 16,
crtc_x, crtc_y, crtc_w, crtc_h);
 
+   /* it's an error to try an unsupported format */
+   format = igt_plane_get_fb_format(plane);
+   igt_assert(igt_plane_supports_format(plane, format));
+
ret = drmModeSetPlane(display->drm_fd,
  plane->drm_plane->plane_id,
  crtc_id,
-- 
2.7.4

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

[Intel-gfx] [PATCH i-g-t 0/2] Improve error report when there are less overlays than expected

[Tomeu Vizoso]

Hi,

kms_plane_scaling would happily try to use the cursor plane as if it was an
overlay, and the first signal of it would be the kernel refusing the SetPlane
call because of the pixel format not matching.

To improve this situation, we check the format of the framebuffer before
calling SetPlane (printing the supported formats), and skip the test if there
aren't enough overlay planes.

Thanks,

Tomeu

Tomeu Vizoso (2):
  lib: Check format of framebuffer before SetPlane
  kms_plane_scaling: Skip if we don't have enough overlays

 lib/igt_kms.c | 35 +++
 tests/kms_plane_scaling.c |  4 
 2 files changed, 39 insertions(+)

-- 
2.7.4

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

[Intel-gfx] [PATCH i-g-t 2/2] kms_plane_scaling: Skip if we don't have enough overlays

[Tomeu Vizoso]

The test currently assumes that there are two overlay planes available,
but that's not generally true and from the error that returns the
kernel, it isn't obvious what's going on.

Signed-off-by: Tomeu Vizoso 
---
 tests/kms_plane_scaling.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/tests/kms_plane_scaling.c b/tests/kms_plane_scaling.c
index 4546ce548515..0e2a875c6542 100644
--- a/tests/kms_plane_scaling.c
+++ b/tests/kms_plane_scaling.c
@@ -229,6 +229,8 @@ static void test_plane_scaling(data_t *d)
 
/* Set up fb2->plane2 mapping. */
d->plane2 = igt_output_get_plane(output, IGT_PLANE_2);
+   if(d->plane2->is_cursor)
+   continue;
igt_plane_set_fb(d->plane2, >fb2);
 
/* 2nd plane windowed */
@@ -265,6 +267,8 @@ static void test_plane_scaling(data_t *d)
 
/* Set up fb3->plane3 mapping. */
d->plane3 = igt_output_get_plane(output, IGT_PLANE_3);
+   if(d->plane3->is_cursor)
+   continue;
igt_plane_set_fb(d->plane3, >fb3);
 
/* 3rd plane windowed - no scaling */
-- 
2.7.4

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