[Intel-gfx] ✗ Fi.CI.BAT: failure for Try to fix MST regression with DDI IO power domains

[Patchwork]

== Series Details ==

Series: Try to fix MST regression with DDI IO power domains
URL   : https://patchwork.freedesktop.org/series/20345/
State : failure

== Summary ==

Series 20345v1 Try to fix MST regression with DDI IO power domains
https://patchwork.freedesktop.org/api/1.0/series/20345/revisions/1/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
pass   -> FAIL   (fi-snb-2600)
Test gem_exec_parallel:
Subgroup basic:
pass   -> DMESG-WARN (fi-skl-6700hq)

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:108  pass:95   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:278  pass:260  dwarn:1   dfail:0   fail:0   skip:17 
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:1   skip:29 

1a8bd0fb40e5d02f827f925b7702ed6f64fadce2 drm-tip: 2017y-02m-27d-22h-04m-19s UTC 
integration manifest
a225efb drm/i915: Remove duplicate DDI enabling logic from MST path
a6623f1 drm/i915: Enable DDI IO power domains in the DP MST path

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915: Consolidate reporting of "missed breadcrumbs"

[Tvrtko Ursulin]

On 27/02/2017 23:41, Chris Wilson wrote:

Move the setting of gpu_error->missed_irq_ring bit to a common function
so that we can get the debug logging for either path.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_breadcrumbs.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index 7c7867d65a39..695ecec52d50 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -59,6 +59,16 @@ static unsigned long wait_timeout(void)
return round_jiffies_up(jiffies + DRM_I915_HANGCHECK_JIFFIES);
 }

+static void missed_breadcrumb(struct intel_engine_cs *engine)
+{
+   DRM_DEBUG_DRIVER("%s missed breadcrumb, irq posted? %s\n",
+engine->name,
+yesno(test_bit(ENGINE_IRQ_BREADCRUMB,
+   >irq_posted)));
+
+   set_bit(engine->id, >i915->gpu_error.missed_irq_rings);
+}
+
 static void intel_breadcrumbs_hangcheck(unsigned long data)
 {
struct intel_engine_cs *engine = (struct intel_engine_cs *)data;
@@ -86,8 +96,7 @@ static void intel_breadcrumbs_hangcheck(unsigned long data)
 * DRM_I915_HANGCHECK_JIFFIES [1.5s]!
 */
if (intel_engine_wakeup(engine) & ENGINE_WAKEUP_ASLEEP) {
-   DRM_DEBUG("Hangcheck timer elapsed... %s idle\n", engine->name);
-   set_bit(engine->id, >i915->gpu_error.missed_irq_rings);
+   missed_breadcrumb(engine);
mod_timer(>breadcrumbs.fake_irq, jiffies + 1);
} else {
mod_timer(>hangcheck, wait_timeout());
@@ -180,7 +189,7 @@ void intel_engine_disarm_breadcrumbs(struct intel_engine_cs 
*engine)
 * completion.
 */
if (__intel_breadcrumbs_wakeup(b) & ENGINE_WAKEUP_ASLEEP)
-   set_bit(engine->id, >i915->gpu_error.missed_irq_rings);
+   missed_breadcrumb(engine);

__intel_engine_disarm_breadcrumbs(engine);




Reviewed-by: Tvrtko Ursulin 

Regards,

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

Re: [Intel-gfx] [PATCH] drm/i915: Only enable DDI IO power domains after enabling DPLL

[Ander Conselvan De Oliveira]

On Mon, 2017-02-27 at 22:38 +0200, Ville Syrjälä wrote:
> On Fri, Feb 24, 2017 at 04:19:59PM +0200, Ander Conselvan de Oliveira wrote:
> > According to bspec, the DDI IO power domains should be enabled after
> > enabling the DPLL and mapping it to the DDI. The current order doesn't
> > seem to create problems with Skylake and Kabylake, but causes enable
> > timeouts in Geminilake.
> 
> This one seems to kill SKL+MST.
> 
> Just load the driver with an MST display plugged in and we get:
> [   79.389527] Kernel panic - not syncing: Timeout: Not all CPUs entered 
> broadcast exception handler
> 
> So presumably we're trying to access something that's not powered/clocked
> and the CPU just gets totally stuck.

Hmm, we need to enable the DDI IO power domain in the MST path too. /o\

I sent the fix as a separate series so CI doesn't get confused, although it
doesn't seem to test MST+SKL.

https://patchwork.freedesktop.org/series/20345/

Ander


> 
> > 
> > v2: Rebase.
> >   - Take power domain references before sanitizing encoders. (Imre)
> >   - Add comment to get_encoder_power_domains() defition. (Ander)
> > 
> > v3: Don't put the domain if called with HSW/BDW's analog encoder. (CI)
> > 
> > v4: Put IO power domain before unmapping DPLL. (Imre)
> >   - Change return type of intel_ddi_get_power_domains() to u64. (Imre)
> > 
> > Cc: David Weinehall 
> > Cc: Imre Deak 
> > Signed-off-by: Ander Conselvan de Oliveira 
> > 
> > Reviewed-by: David Weinehall  # v1
> > Reviewed-by: Imre Deak 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h |  5 +++
> >  drivers/gpu/drm/i915/intel_ddi.c| 49 
> >  drivers/gpu/drm/i915/intel_display.c| 20 ++
> >  drivers/gpu/drm/i915/intel_drv.h|  4 ++
> >  drivers/gpu/drm/i915/intel_runtime_pm.c | 68 
> > +++--
> >  5 files changed, 117 insertions(+), 29 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 4673912..5a032ba 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -344,6 +344,11 @@ enum intel_display_power_domain {
> > POWER_DOMAIN_PORT_DDI_C_LANES,
> > POWER_DOMAIN_PORT_DDI_D_LANES,
> > POWER_DOMAIN_PORT_DDI_E_LANES,
> > +   POWER_DOMAIN_PORT_DDI_A_IO,
> > +   POWER_DOMAIN_PORT_DDI_B_IO,
> > +   POWER_DOMAIN_PORT_DDI_C_IO,
> > +   POWER_DOMAIN_PORT_DDI_D_IO,
> > +   POWER_DOMAIN_PORT_DDI_E_IO,
> > POWER_DOMAIN_PORT_DSI,
> > POWER_DOMAIN_PORT_CRT,
> > POWER_DOMAIN_PORT_OTHER,
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index b0c4d23..e9013f1 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -1440,6 +1440,17 @@ bool intel_ddi_get_hw_state(struct intel_encoder 
> > *encoder,
> > return ret;
> >  }
> >  
> > +static u64 intel_ddi_get_power_domains(struct intel_encoder *encoder)
> > +{
> > +   struct intel_digital_port *dig_port = enc_to_dig_port(>base);
> > +   enum pipe pipe;
> > +
> > +   if (intel_ddi_get_hw_state(encoder, ))
> > +   return BIT_ULL(dig_port->ddi_io_power_domain);
> > +
> > +   return 0;
> > +}
> > +
> >  void intel_ddi_enable_pipe_clock(struct intel_crtc *intel_crtc)
> >  {
> > struct drm_crtc *crtc = _crtc->base;
> > @@ -1682,6 +1693,7 @@ static void intel_ddi_pre_enable_dp(struct 
> > intel_encoder *encoder,
> > struct intel_dp *intel_dp = enc_to_intel_dp(>base);
> > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > enum port port = intel_ddi_get_encoder_port(encoder);
> > +   struct intel_digital_port *dig_port = enc_to_dig_port(>base);
> >  
> > intel_dp_set_link_params(intel_dp, link_rate, lane_count,
> >  link_mst);
> > @@ -1689,6 +1701,9 @@ static void intel_ddi_pre_enable_dp(struct 
> > intel_encoder *encoder,
> > intel_edp_panel_on(intel_dp);
> >  
> > intel_ddi_clk_select(encoder, pll);
> > +
> > +   intel_display_power_get(dev_priv, dig_port->ddi_io_power_domain);
> > +
> > intel_prepare_dp_ddi_buffers(encoder);
> > intel_ddi_init_dp_buf_reg(encoder);
> > intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> > @@ -1708,9 +1723,13 @@ static void intel_ddi_pre_enable_hdmi(struct 
> > intel_encoder *encoder,
> > struct drm_encoder *drm_encoder = >base;
> > enum port port = intel_ddi_get_encoder_port(encoder);
> > int level = intel_ddi_hdmi_level(dev_priv, port);
> > +   struct intel_digital_port *dig_port = enc_to_dig_port(>base);
> >  
> > intel_dp_dual_mode_set_tmds_output(intel_hdmi, true);
> > intel_ddi_clk_select(encoder, pll);
> > +
> > +   intel_display_power_get(dev_priv, dig_port->ddi_io_power_domain);
> > +
> > intel_prepare_hdmi_ddi_buffers(encoder);
> > if 

[Intel-gfx] [PATCH 1/2] drm/i915: Enable DDI IO power domains in the DP MST path

[Ander Conselvan de Oliveira]

Commit 62b695662a24 ("drm/i915: Only enable DDI IO power domains after
enabling DPLL") changed how the DDI IO power domains get enabled, but
neglected the need to enable those domains when enabling a DP connector
with MST enabled, leading to

Kernel panic - not syncing: Timeout: Not all CPUs entered broadcast 
exception handler

Fixes: 62b695662a24 ("drm/i915: Only enable DDI IO power domains after enabling 
DPLL")
Cc: David Weinehall 
Cc: Imre Deak 
Cc: Ander Conselvan de Oliveira 
Cc: David Weinehall 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: intel-gfx@lists.freedesktop.org
Cc: Ville Syrjälä 
Reported-by: Ville Syrjälä 
Signed-off-by: Ander Conselvan de Oliveira 

---
 drivers/gpu/drm/i915/intel_dp_mst.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index d94fd4b..a8334e1 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -163,6 +163,9 @@ static void intel_mst_pre_enable_dp(struct intel_encoder 
*encoder,
intel_ddi_clk_select(_dig_port->base,
 pipe_config->shared_dpll);
 
+   intel_display_power_get(dev_priv,
+   intel_dig_port->ddi_io_power_domain);
+
intel_prepare_dp_ddi_buffers(_dig_port->base);
intel_dp_set_link_params(intel_dp,
 pipe_config->port_clock,
-- 
2.9.3

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

[Intel-gfx] [PATCH 2/2] drm/i915: Remove duplicate DDI enabling logic from MST path

[Ander Conselvan de Oliveira]

The logic to enable a DDI in intel_mst_pre_enable_dp() is essentially
the same as in intel_ddi_pre_enable_dp(). So reuse the latter function
by calling the post_disable hook on the intel_dig_port instead of
duplicating that code.

Cc: Ville Syrjälä 
Signed-off-by: Ander Conselvan de Oliveira 

---
 drivers/gpu/drm/i915/intel_ddi.c|  2 ++
 drivers/gpu/drm/i915/intel_dp_mst.c | 23 +++
 2 files changed, 5 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index e9013f1..71aaddf 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1695,6 +1695,8 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder 
*encoder,
enum port port = intel_ddi_get_encoder_port(encoder);
struct intel_digital_port *dig_port = enc_to_dig_port(>base);
 
+   WARN_ON(link_mst && port == PORT_A);
+
intel_dp_set_link_params(intel_dp, link_rate, lane_count,
 link_mst);
if (encoder->type == INTEL_OUTPUT_EDP)
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index a8334e1..094cbdc 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -159,26 +159,9 @@ static void intel_mst_pre_enable_dp(struct intel_encoder 
*encoder,
 
DRM_DEBUG_KMS("%d\n", intel_dp->active_mst_links);
 
-   if (intel_dp->active_mst_links == 0) {
-   intel_ddi_clk_select(_dig_port->base,
-pipe_config->shared_dpll);
-
-   intel_display_power_get(dev_priv,
-   intel_dig_port->ddi_io_power_domain);
-
-   intel_prepare_dp_ddi_buffers(_dig_port->base);
-   intel_dp_set_link_params(intel_dp,
-pipe_config->port_clock,
-pipe_config->lane_count,
-true);
-
-   intel_ddi_init_dp_buf_reg(_dig_port->base);
-
-   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
-
-   intel_dp_start_link_train(intel_dp);
-   intel_dp_stop_link_train(intel_dp);
-   }
+   if (intel_dp->active_mst_links == 0)
+   intel_dig_port->base.pre_enable(_dig_port->base,
+   pipe_config, NULL);
 
ret = drm_dp_mst_allocate_vcpi(_dp->mst_mgr,
   connector->port,
-- 
2.9.3

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

[Intel-gfx] [PATCH 0/2] Try to fix MST regression with DDI IO power domains

[Ander Conselvan de Oliveira]

Hi,

Commit 62b695662a24 ("drm/i915: Only enable DDI IO power domains after
enabling DPLL") seems to have broken MST. Here's an untested fix (I
don't have the right hardware to test this at the moment).

Thanks,
Ander

Ander Conselvan de Oliveira (2):
  drm/i915: Enable DDI IO power domains in the DP MST path
  drm/i915: Remove duplicate DDI enabling logic from MST path

 drivers/gpu/drm/i915/intel_ddi.c|  2 ++
 drivers/gpu/drm/i915/intel_dp_mst.c | 20 +++-
 2 files changed, 5 insertions(+), 17 deletions(-)

-- 
2.9.3

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

Re: [Intel-gfx] [PATCH] drm/915/glk: Enable pooled EUs for Geminilake

[Yang, Rong R]

We suggest GLK could disable pooled EUs for 2x6 configurations too.
As I understand, 2x6 a pool must consist of a complete subslice, 12EUs, right?
If so, only 64K SLM are valid, I am afraid it may affect some case's 
performance.

> -Original Message-
> From: Conselvan De Oliveira, Ander
> Sent: Friday, February 24, 2017 21:13
> To: intel-gfx@lists.freedesktop.org
> Cc: Conselvan De Oliveira, Ander ;
> Arun Siluvery ; Kuoppala, Mika
> ; Ursulin, Tvrtko ;
> Yang, Rong R 
> Subject: [PATCH] drm/915/glk: Enable pooled EUs for Geminilake
> 
> Geminilake also supports pooled EUs. Enable it.
> 
> It is unclear if the recommendation to disable it for 2x6 configurations from
> commit e015dd69b2cf ("drm/i915/bxt: Add WaEnablePooledEuFor2x6")
> should also apply to GLK, but the only userspace that uses this only cares
> about the 3x6 configuration. See Beignet's commit 6901899ec90a
> ("Runtime: set the sub slice according to kernel pooled EU configure.").
> 
> Cc: Arun Siluvery 
> Cc: Mika Kuoppala 
> Cc: Tvrtko Ursulin 
> Cc: Yang Rong 
> Signed-off-by: Ander Conselvan de Oliveira
> 
> ---
>  drivers/gpu/drm/i915/intel_device_info.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_device_info.c
> b/drivers/gpu/drm/i915/intel_device_info.c
> index 2e1fd85..198752d 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.c
> +++ b/drivers/gpu/drm/i915/intel_device_info.c
> @@ -195,8 +195,10 @@ static void gen9_sseu_info_init(struct
> drm_i915_private *dev_priv)
>   IS_GEN9_LP(dev_priv) && sseu_subslice_total(sseu) > 1;
>   sseu->has_eu_pg = sseu->eu_per_subslice > 2;
> 
> - if (IS_BROXTON(dev_priv)) {
> + if (IS_GEN9_LP(dev_priv)) {
>  #define IS_SS_DISABLED(ss)   (!(sseu->subslice_mask & BIT(ss)))
> + info->has_pooled_eu = hweight8(sseu->subslice_mask) == 3;
> +
>   /*
>* There is a HW issue in 2x6 fused down parts that requires
>* Pooled EU to be enabled as a WA. The pool configuration
> @@ -204,9 +206,8 @@ static void gen9_sseu_info_init(struct
> drm_i915_private *dev_priv)
>* doesn't affect if the device has all 3 subslices enabled.
>*/
>   /* WaEnablePooledEuFor2x6:bxt */
> - info->has_pooled_eu = ((hweight8(sseu->subslice_mask) ==
> 3) ||
> -(hweight8(sseu->subslice_mask) == 2 &&
> - INTEL_REVID(dev_priv) <
> BXT_REVID_C0));
> + info->has_pooled_eu |= (hweight8(sseu->subslice_mask) ==
> 2 &&
> + IS_BXT_REVID(dev_priv, 0,
> BXT_REVID_B_LAST));
> 
>   sseu->min_eu_in_pool = 0;
>   if (info->has_pooled_eu) {
> --
> 2.9.3

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

Re: [Intel-gfx] [PATCH 01/15] drm/i915: Copy user requested buffers into the error state

[Ben Widawsky]

On 17-02-23 16:18:16, Chris Wilson wrote:

Introduce a new execobject.flag (EXEC_OBJECT_CAPTURE) that userspace may
use to indicate that it wants the contents of this buffer preserved in
the error state (/sys/class/drm/cardN/error) following a GPU hang
involving this batch.

Use this at your discretion, the contents of the error state. although
compressed, are allocated with GFP_ATOMIC (i.e. limited) and kept for all
eternity (until the error state is destroyed).

Based on an earlier patch by Ben Widawsky 
Signed-off-by: Chris Wilson 
Cc: Ben Widawsky 
Cc: Matt Turner 


Haven't tested it or used it, but I wanted it.
Acked-by: Ben Widawsky 


---
drivers/gpu/drm/i915/i915_drv.c|  1 +
drivers/gpu/drm/i915/i915_drv.h|  3 +++
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 12 +
drivers/gpu/drm/i915/i915_gem_request.c| 16 
drivers/gpu/drm/i915/i915_gem_request.h| 11 
drivers/gpu/drm/i915/i915_gpu_error.c  | 40 +-
include/uapi/drm/i915_drm.h| 15 ++-
7 files changed, 96 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 409fc32ce2bd..842c62b96a83 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -353,6 +353,7 @@ static int i915_getparam(struct drm_device *dev, void *data,
case I915_PARAM_HAS_EXEC_ASYNC:
case I915_PARAM_HAS_EXEC_FENCE:
case I915_PARAM_HAS_EXEC_FENCE_DMABUF:
+   case I915_PARAM_HAS_EXEC_CAPTURE:
/* For the time being all of these are always true;
 * if some supported hardware does not have one of these
 * features this value needs to be provided from
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 440a4725b87f..2cc0253d6ef7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1018,6 +1018,9 @@ struct i915_gpu_state {
u32 *pages[0];
} *ringbuffer, *batchbuffer, *wa_batchbuffer, *ctx, *hws_page;

+   struct drm_i915_error_object **user_bo;
+   long user_bo_count;
+
struct drm_i915_error_object *wa_ctx;

struct drm_i915_error_request {
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 3f2796131410..e8ffe0c9a20e 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1113,6 +1113,18 @@ i915_gem_execbuffer_move_to_gpu(struct 
drm_i915_gem_request *req,
list_for_each_entry(vma, vmas, exec_list) {
struct drm_i915_gem_object *obj = vma->obj;

+   if (vma->exec_entry->flags & EXEC_OBJECT_CAPTURE) {
+   struct i915_gem_capture_list *capture;
+
+   capture = kmalloc(sizeof(*capture), GFP_KERNEL);
+   if (unlikely(!capture))
+   return -ENOMEM;
+
+   capture->next = req->capture_list;
+   capture->vma = vma;
+   req->capture_list = capture;
+   }
+
if (vma->exec_entry->flags & EXEC_OBJECT_ASYNC)
continue;

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index ad9d4ce07fb6..3a159cac2172 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -286,6 +286,19 @@ void i915_gem_retire_noop(struct i915_gem_active *active,
/* Space left intentionally blank */
}

+static void request_free_capture_list(struct drm_i915_gem_request *request)
+{
+   struct i915_gem_capture_list *capture;
+
+   capture = request->capture_list;
+   while (capture) {
+   struct i915_gem_capture_list *next = capture->next;
+
+   kfree(capture);
+   capture = next;
+   }
+}
+
static void i915_gem_request_retire(struct drm_i915_gem_request *request)
{
struct intel_engine_cs *engine = request->engine;
@@ -320,6 +333,8 @@ static void i915_gem_request_retire(struct 
drm_i915_gem_request *request)
}
unreserve_seqno(request->engine);

+   request_free_capture_list(request);
+
/* Walk through the active list, calling retire on each. This allows
 * objects to track their GPU activity and mark themselves as idle
 * when their *last* active request is completed (updating state
@@ -615,6 +630,7 @@ i915_gem_request_alloc(struct intel_engine_cs *engine,
req->global_seqno = 0;
req->file_priv = NULL;
req->batch = NULL;
+   req->capture_list = NULL;

/*
 * Reserve space in the ring buffer for all the commands required to

Re: [Intel-gfx] [PATCH 8/9] drm/i915: Implement .get_format_info() hook for CCS

[Ben Widawsky]

On 17-02-27 17:13:41, Ville Syrjälä wrote:

On Sun, Feb 26, 2017 at 02:41:50PM -0800, Chad Versace wrote:

On Wed 04 Jan 2017, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
>
> SKL+ display engine can scan out certain kinds of compressed surfaces
> produced by the render engine. This involved telling the display engine
> the location of the color control surfae (CCS) which describes which
> parts of the main surface are compressed and which are not. The location
> of CCS is provided by userspace as just another plane with its own offset.
>
> By providing our own format information for the CCS formats, we should
> be able to make framebuffer_check() do the right thing for the CCS
> surface as well.
>
> Note that we'll return the same format info for both Y and Yf tiled
> format as that's what happens with the non-CCS Y vs. Yf as well. If
> desired, we could potentially return a unique pointer for each
> pixel_format+tiling+ccs combination, in which case we immediately be
> able to tell if any of that stuff changed by just comparing the
> pointers. But that does sound a bit wasteful space wise.
>
> v2: Drop the 'dev' argument from the hook
> v3: Include the description of the CCS surface layout
>
> Cc: Vandana Kannan 
> Cc: Daniel Vetter 
> Cc: Ben Widawsky 
> Cc: Jason Ekstrand 
> Reviewed-by: Ben Widawsky 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 36 ++
>  include/uapi/drm/drm_fourcc.h| 49 

>  2 files changed, 85 insertions(+)


> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 9e1bb7fabcde..4581e3d41e5c 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -230,6 +230,55 @@ extern "C" {
>  #define I915_FORMAT_MOD_Yf_TILED fourcc_mod_code(INTEL, 3)
>
>  /*
> + * Intel color control surface (CCS) for render compression
> + *
> + * The framebuffer format must be one of the 8:8:8:8 RGB formats,
> + * the main surface will be plane index 0 and will be Y/Yf-tiled,
> + * the CCS will be plane index 1.
> + *

The paragraph below is...

> + * Each byte of CCS contains 4 pairs of bits, with each pair of bits
> + * matching an area of 8x4 pixels of the main surface. Which would seem
> + * to match 2 cachelines containing 4x4 pixels each. The pairs bits within
> + * the byte form a 2x2 grid, which thus matches a 16x8 pixel area of the
> + * main surface. This is the 2x2 pattern the bits form (0=lsb, 7=msb):
> + * ---
> + * | 01 | 23 |
> + *  --
> + * | 45 | 67 |
> + * ---

...almost correct. The hw docs state that each bit-pair of the CCS maps
cacheline-pair, horizontally adjacent in the Y tile, of the primary surface. As
a consequence, the remainder of the above paragraph is correct for 32-bit
formats, but not others.


Which is why the comment says at the very top that the fb needs to
use a 8:8:8:8 format. IIRC that's the only thing the hardware supports.



It is, and it is for the foreseeable future too. Chad, granted you say this
isn't a nitpick below, but it is because Ville's patch is for the KMS case, it's
not entirely relevant here.




This is not a nitpick, because Vulkan and EGL users may want to share
dma_bufs with a fat format like R32G32B32A32_UNORM, and want to have CCS
enabled when possible. As long as the users use the dma_buf only the 3D
engine, and don't submit it to KMS, it's all safe.

For those users, we should document the bit-pair/cacheline-pair relationship
correctly. And then preface the following detailed explanation and nice ascii
diagrams by saying "this applies only to the 32-bit formats".

Here's the relevant PRM quote:

 The Color Control Surface (CCS) contains the compression status
 of the cache-line pairs. The compression state of the cache-line
 pair is specified by 2 bits in the CCS.  Each CCS cache-line
 represents an area on the main surface of 16x16 sets of 128 byte
 Y-tiled cache-line-pairs. CCS is always Y tiled.

See this Mesa comment for more details:
https://cgit.freedesktop.org/mesa/mesa/tree/src/intel/isl/isl.c?h=17.0#n211

> + * Actually only the lower bit of the pair seems to have any effect.
> + * No idea why. 0 in the lower bit would seem to mean not compressed,
> + * and 1 is compressed.  The interpreation of the main surface data
> + * when the block is marked compressed is unknown as of now.

If I recall correctly (it's been several months since I inspected the
bits), the high bit is actually significant. Bit pattern 11 means that
the data in primary surface's cacheline-pair is invalid; the 3D engine
interprets the color of all pixels in that cacheline-pair to be the
clear color stored in RENDER_SURFACE_STATE. Before the display engine
can consume the surface, userspace 

Re: [Intel-gfx] [PATCH v2] Add the new tool for create GVT-g Linux guest based on KVMGT

[Xu, Terrence]

>On 02/27/2017 10:13 AM, Xu, Terrence wrote:
>> [Xu, Terrence] Yes the root is needed for all our "echo" related commands,
>can I suppose the case is running under root privilege? Or need to return
>"skip" when it is not under root privilege?
>>
>
>Right, seems I was a bit confused there and there are other cases where root
>rights are required.
>
>Assuming root privileges is fine, especially if you're nice and warn the user 
>if
>proper rights are not active. Can the tool be used as a normal user at all?
[Xu, Terrence] It cannot be used as a normal user, since it need to call the 
sysfs, so I will choose to warn the user if proper rights are not active. :)

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Force uncached PPAT for debugging purposes.

[Patchwork]

== Series Details ==

Series: drm/i915: Force uncached PPAT for debugging purposes.
URL   : https://patchwork.freedesktop.org/series/20334/
State : success

== Summary ==

Series 20334v1 drm/i915: Force uncached PPAT for debugging purposes.
https://patchwork.freedesktop.org/api/1.0/series/20334/revisions/1/mbox/

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:108  pass:95   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29 

1a8bd0fb40e5d02f827f925b7702ed6f64fadce2 drm-tip: 2017y-02m-27d-22h-04m-19s UTC 
integration manifest
0560c81 drm/i915: Force uncached PPAT for debugging purposes.

== Logs ==

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

[Intel-gfx] [PATCH 2/2] gpu: drm: Convert printk(KERN_ to pr_

[Joe Perches]

Use a more common logging style.

Miscellanea:

o Coalesce formats and realign arguments
o Neaten a few macros now using pr_

Signed-off-by: Joe Perches 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h|  3 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_afmt.c   |  4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c   |  4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c |  3 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_test.c   |  2 +-
 drivers/gpu/drm/amd/amdgpu/atom.c  | 44 -
 drivers/gpu/drm/amd/amdgpu/ci_dpm.c|  4 +-
 drivers/gpu/drm/amd/amdgpu/cik_sdma.c  |  4 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c  |  4 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c  |  4 +-
 drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c  |  8 ++--
 drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c  |  8 ++--
 drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c |  4 +-
 drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c |  4 +-
 drivers/gpu/drm/amd/include/amd_pcie_helpers.h |  4 +-
 drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c   |  2 +-
 drivers/gpu/drm/amd/powerplay/inc/pp_debug.h   |  2 +-
 drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c|  4 +-
 drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c | 14 +++---
 .../gpu/drm/amd/powerplay/smumgr/polaris10_smc.c   |  4 +-
 drivers/gpu/drm/amd/powerplay/smumgr/tonga_smc.c   |  4 +-
 drivers/gpu/drm/drm_cache.c| 12 ++---
 drivers/gpu/drm/drm_edid.c |  4 +-
 drivers/gpu/drm/drm_ioc32.c|  3 +-
 drivers/gpu/drm/gma500/cdv_intel_lvds.c|  9 ++--
 drivers/gpu/drm/gma500/oaktrail_lvds.c | 18 +++
 drivers/gpu/drm/gma500/psb_drv.h   |  5 +-
 drivers/gpu/drm/gma500/psb_intel_lvds.c|  7 ++-
 drivers/gpu/drm/i915/i915_sw_fence.c   |  8 ++--
 drivers/gpu/drm/mgag200/mgag200_mode.c |  2 +-
 drivers/gpu/drm/msm/msm_drv.c  |  2 +-
 drivers/gpu/drm/nouveau/nouveau_acpi.c |  7 +--
 drivers/gpu/drm/nouveau/nouveau_vga.c  |  4 +-
 drivers/gpu/drm/nouveau/nv50_display.c | 22 -
 drivers/gpu/drm/nouveau/nvkm/core/mm.c | 10 ++--
 drivers/gpu/drm/omapdrm/dss/dsi.c  | 17 ---
 drivers/gpu/drm/omapdrm/dss/dss.c  |  3 +-
 drivers/gpu/drm/omapdrm/dss/dss.h  | 15 +++---
 drivers/gpu/drm/omapdrm/omap_gem.c |  5 +-
 drivers/gpu/drm/r128/r128_cce.c|  7 ++-
 drivers/gpu/drm/radeon/atom.c  | 46 --
 drivers/gpu/drm/radeon/cik.c   | 56 --
 drivers/gpu/drm/radeon/evergreen.c |  2 +-
 drivers/gpu/drm/radeon/evergreen_cs.c  |  7 ++-
 drivers/gpu/drm/radeon/ni.c| 22 +++--
 drivers/gpu/drm/radeon/r100.c  | 18 +++
 drivers/gpu/drm/radeon/r200.c  |  3 +-
 drivers/gpu/drm/radeon/r300.c  | 13 ++---
 drivers/gpu/drm/radeon/r420.c  |  9 ++--
 drivers/gpu/drm/radeon/r520.c  |  3 +-
 drivers/gpu/drm/radeon/r600.c  | 21 +++-
 drivers/gpu/drm/radeon/r600_cs.c   |  7 ++-
 drivers/gpu/drm/radeon/radeon.h|  3 +-
 drivers/gpu/drm/radeon/radeon_atpx_handler.c   |  4 +-
 drivers/gpu/drm/radeon/radeon_audio.c  |  4 +-
 drivers/gpu/drm/radeon/radeon_clocks.c |  2 +-
 drivers/gpu/drm/radeon/radeon_device.c |  8 ++--
 drivers/gpu/drm/radeon/radeon_fb.c |  3 +-
 drivers/gpu/drm/radeon/radeon_gem.c|  4 +-
 drivers/gpu/drm/radeon/radeon_test.c   |  6 +--
 drivers/gpu/drm/radeon/rs400.c |  4 +-
 drivers/gpu/drm/radeon/rs690.c |  3 +-
 drivers/gpu/drm/radeon/rv515.c |  9 ++--
 drivers/gpu/drm/radeon/si.c| 45 ++---
 drivers/gpu/drm/ttm/ttm_bo.c   |  2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_fence.c  |  6 +--
 drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c  |  3 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c   |  4 +-
 69 files changed, 253 insertions(+), 362 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index c1b913541739..3f636632c289 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1515,7 +1515,8 @@ void amdgpu_mm_wdoorbell(struct amdgpu_device *adev, u32 
index, u32 v);
  */
 #define RREG32(reg) amdgpu_mm_rreg(adev, (reg), false)
 #define RREG32_IDX(reg) amdgpu_mm_rreg(adev, (reg), true)
-#define DREG32(reg) printk(KERN_INFO "REGISTER: " #reg " : 

[Intel-gfx] [PATCH 0/2] gpu: drm: Use pr_cont and neaten logging

[Joe Perches]

Joe Perches (2):
  drm: Use pr_cont where appropriate
  gpu: drm: Convert printk(KERN_ to pr_

 drivers/gpu/drm/amd/amdgpu/amdgpu.h|  3 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_afmt.c   |  4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c   |  4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.c| 70 ++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c |  3 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_test.c   |  2 +-
 drivers/gpu/drm/amd/amdgpu/atom.c  | 44 ++
 drivers/gpu/drm/amd/amdgpu/ci_dpm.c|  4 +-
 drivers/gpu/drm/amd/amdgpu/cik_sdma.c  |  4 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c  |  4 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c  |  4 +-
 drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c  |  8 +--
 drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c  |  8 +--
 drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c |  4 +-
 drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c |  4 +-
 drivers/gpu/drm/amd/include/amd_pcie_helpers.h |  4 +-
 drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c   |  2 +-
 drivers/gpu/drm/amd/powerplay/inc/pp_debug.h   |  2 +-
 drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c|  4 +-
 drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c | 14 ++---
 .../gpu/drm/amd/powerplay/smumgr/polaris10_smc.c   |  4 +-
 drivers/gpu/drm/amd/powerplay/smumgr/tonga_smc.c   |  4 +-
 drivers/gpu/drm/drm_cache.c| 12 ++--
 drivers/gpu/drm/drm_edid.c |  4 +-
 drivers/gpu/drm/drm_ioc32.c|  3 +-
 drivers/gpu/drm/gma500/cdv_intel_lvds.c|  9 ++-
 drivers/gpu/drm/gma500/oaktrail_lvds.c | 18 +++---
 drivers/gpu/drm/gma500/psb_drv.h   |  5 +-
 drivers/gpu/drm/gma500/psb_intel_lvds.c|  7 +--
 drivers/gpu/drm/i915/i915_sw_fence.c   |  8 +--
 drivers/gpu/drm/mgag200/mgag200_mode.c |  2 +-
 drivers/gpu/drm/msm/msm_drv.c  |  2 +-
 drivers/gpu/drm/nouveau/nouveau_acpi.c |  7 ++-
 drivers/gpu/drm/nouveau/nouveau_vga.c  |  4 +-
 drivers/gpu/drm/nouveau/nv50_display.c | 22 +++
 drivers/gpu/drm/nouveau/nvkm/core/mm.c | 10 +--
 drivers/gpu/drm/omapdrm/dss/dsi.c  | 17 +++---
 drivers/gpu/drm/omapdrm/dss/dss.c  |  3 +-
 drivers/gpu/drm/omapdrm/dss/dss.h  | 15 ++---
 drivers/gpu/drm/omapdrm/omap_gem.c |  5 +-
 drivers/gpu/drm/r128/r128_cce.c|  7 +--
 drivers/gpu/drm/radeon/atom.c  | 46 ++
 drivers/gpu/drm/radeon/cik.c   | 56 ++---
 drivers/gpu/drm/radeon/evergreen.c |  2 +-
 drivers/gpu/drm/radeon/evergreen_cs.c  |  7 +--
 drivers/gpu/drm/radeon/ni.c| 22 +++
 drivers/gpu/drm/radeon/r100.c  | 18 ++
 drivers/gpu/drm/radeon/r200.c  |  3 +-
 drivers/gpu/drm/radeon/r300.c  | 13 ++--
 drivers/gpu/drm/radeon/r420.c  |  9 +--
 drivers/gpu/drm/radeon/r520.c  |  3 +-
 drivers/gpu/drm/radeon/r600.c  | 21 +++
 drivers/gpu/drm/radeon/r600_cs.c   |  7 +--
 drivers/gpu/drm/radeon/r600_dpm.c  | 71 +++---
 drivers/gpu/drm/radeon/radeon.h|  3 +-
 drivers/gpu/drm/radeon/radeon_atpx_handler.c   |  4 +-
 drivers/gpu/drm/radeon/radeon_audio.c  |  4 +-
 drivers/gpu/drm/radeon/radeon_clocks.c |  2 +-
 drivers/gpu/drm/radeon/radeon_device.c |  8 +--
 drivers/gpu/drm/radeon/radeon_fb.c |  3 +-
 drivers/gpu/drm/radeon/radeon_gem.c|  4 +-
 drivers/gpu/drm/radeon/radeon_test.c   |  6 +-
 drivers/gpu/drm/radeon/rs400.c |  4 +-
 drivers/gpu/drm/radeon/rs690.c |  3 +-
 drivers/gpu/drm/radeon/rv515.c |  9 +--
 drivers/gpu/drm/radeon/si.c| 45 +-
 drivers/gpu/drm/ttm/ttm_bo.c   |  2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_fence.c  |  6 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c  |  3 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c   |  4 +-
 71 files changed, 326 insertions(+), 430 deletions(-)

-- 
2.10.0.rc2.1.g053435c

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

Re: [Intel-gfx] [PATCH] drm/i915: Force uncached PPAT for debugging purposes.

[Ben Widawsky]

On 17-02-27 17:12:07, Rodrigo Vivi wrote:

Many screen corruptions and hangs in the past were somehow
related to the caches. In many situations forcing the uncached
was useful at least to narrow down the issue by confirming it
was cache related.

Instead of having to hardcode it everytime that we suspect on
this table let's provide a mechanism to disable these
cache leves on this private table (PPAT).

Cc: Ben Widawsky 
Cc: Daniele Ceraolo Spurio 
Signed-off-by: Rodrigo Vivi 


I think this is a cool idea, it could equally be achieved by modifying the PTE
encoding function. In my head, modifying the pte encode makes more sense since
it applies to all legacy context, advanced context, and ggtt entries.


---
drivers/gpu/drm/i915/i915_gem_gtt.c | 6 +-
drivers/gpu/drm/i915/i915_params.c  | 5 +
drivers/gpu/drm/i915/i915_params.h  | 1 +
3 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index e0c9542..df9f71e 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2645,7 +2645,10 @@ static int ggtt_probe_common(struct i915_ggtt *ggtt, u64 
size)
 * writing this data shouldn't be harmful even in those cases. */
static void bdw_setup_private_ppat(struct drm_i915_private *dev_priv)
{
-   u64 pat;
+   u64 pat = 0;
+
+   if (i915.uncached_pat)
+   goto out;

pat = GEN8_PPAT(0, GEN8_PPAT_WB | GEN8_PPAT_LLC) | /* for normal 
objects, no eLLC */
  GEN8_PPAT(1, GEN8_PPAT_WC | GEN8_PPAT_LLCELLC) | /* for something 
pointing to ptes? */
@@ -2672,6 +2675,7 @@ static void bdw_setup_private_ppat(struct 
drm_i915_private *dev_priv)
 */
pat = GEN8_PPAT(0, GEN8_PPAT_UC);

+out:
/* XXX: spec defines this as 2 distinct registers. It's unclear if a 64b
 * write would work. */
I915_WRITE(GEN8_PRIVATE_PAT_LO, pat);
diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 2e9645e..505afda 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -37,6 +37,7 @@ struct i915_params i915 __read_mostly = {
.enable_fbc = -1,
.enable_execlists = -1,
.enable_hangcheck = true,
+   .uncached_pat = false,
.enable_ppgtt = -1,
.enable_psr = -1,
.alpha_support = IS_ENABLED(CONFIG_DRM_I915_ALPHA_SUPPORT),
@@ -130,6 +131,10 @@ struct i915_params i915 __read_mostly = {
"WARNING: Disabling this can cause system wide hangs. "
"(default: true)");

+module_param_named_unsafe(uncached_pat, i915.uncached_pat, bool, 0400);
+MODULE_PARM_DESC(uncached_pat,
+   "Force Uncached Private PPAT for debugging purposes. (default:false)");
+
module_param_named_unsafe(enable_ppgtt, i915.enable_ppgtt, int, 0400);
MODULE_PARM_DESC(enable_ppgtt,
"Override PPGTT usage. "
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 55d47ee..2453431 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -54,6 +54,7 @@
func(bool, alpha_support); \
func(bool, enable_cmd_parser); \
func(bool, enable_hangcheck); \
+   func(bool, uncached_pat); \
func(bool, fastboot); \
func(bool, prefault_disable); \
func(bool, load_detect_test); \
--
1.9.1



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

[Intel-gfx] [PATCH] drm/i915: Force uncached PPAT for debugging purposes.

[Rodrigo Vivi]

Many screen corruptions and hangs in the past were somehow
related to the caches. In many situations forcing the uncached
was useful at least to narrow down the issue by confirming it
was cache related.

Instead of having to hardcode it everytime that we suspect on
this table let's provide a mechanism to disable these
cache leves on this private table (PPAT).

Cc: Ben Widawsky 
Cc: Daniele Ceraolo Spurio 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 6 +-
 drivers/gpu/drm/i915/i915_params.c  | 5 +
 drivers/gpu/drm/i915/i915_params.h  | 1 +
 3 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index e0c9542..df9f71e 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2645,7 +2645,10 @@ static int ggtt_probe_common(struct i915_ggtt *ggtt, u64 
size)
  * writing this data shouldn't be harmful even in those cases. */
 static void bdw_setup_private_ppat(struct drm_i915_private *dev_priv)
 {
-   u64 pat;
+   u64 pat = 0;
+
+   if (i915.uncached_pat)
+   goto out;
 
pat = GEN8_PPAT(0, GEN8_PPAT_WB | GEN8_PPAT_LLC) | /* for normal 
objects, no eLLC */
  GEN8_PPAT(1, GEN8_PPAT_WC | GEN8_PPAT_LLCELLC) | /* for something 
pointing to ptes? */
@@ -2672,6 +2675,7 @@ static void bdw_setup_private_ppat(struct 
drm_i915_private *dev_priv)
 */
pat = GEN8_PPAT(0, GEN8_PPAT_UC);
 
+out:
/* XXX: spec defines this as 2 distinct registers. It's unclear if a 64b
 * write would work. */
I915_WRITE(GEN8_PRIVATE_PAT_LO, pat);
diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 2e9645e..505afda 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -37,6 +37,7 @@ struct i915_params i915 __read_mostly = {
.enable_fbc = -1,
.enable_execlists = -1,
.enable_hangcheck = true,
+   .uncached_pat = false,
.enable_ppgtt = -1,
.enable_psr = -1,
.alpha_support = IS_ENABLED(CONFIG_DRM_I915_ALPHA_SUPPORT),
@@ -130,6 +131,10 @@ struct i915_params i915 __read_mostly = {
"WARNING: Disabling this can cause system wide hangs. "
"(default: true)");
 
+module_param_named_unsafe(uncached_pat, i915.uncached_pat, bool, 0400);
+MODULE_PARM_DESC(uncached_pat,
+   "Force Uncached Private PPAT for debugging purposes. (default:false)");
+
 module_param_named_unsafe(enable_ppgtt, i915.enable_ppgtt, int, 0400);
 MODULE_PARM_DESC(enable_ppgtt,
"Override PPGTT usage. "
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 55d47ee..2453431 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -54,6 +54,7 @@
func(bool, alpha_support); \
func(bool, enable_cmd_parser); \
func(bool, enable_hangcheck); \
+   func(bool, uncached_pat); \
func(bool, fastboot); \
func(bool, prefault_disable); \
func(bool, load_detect_test); \
-- 
1.9.1

___
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/i915: Consolidate reporting of "missed breadcrumbs"

[Patchwork]

== Series Details ==

Series: drm/i915: Consolidate reporting of "missed breadcrumbs"
URL   : https://patchwork.freedesktop.org/series/20330/
State : failure

== Summary ==

Series 20330v1 drm/i915: Consolidate reporting of "missed breadcrumbs"
https://patchwork.freedesktop.org/api/1.0/series/20330/revisions/1/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
pass   -> FAIL   (fi-snb-2600)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-byt-n2820)

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:108  pass:95   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:278  pass:246  dwarn:1   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:1   skip:29 

1a8bd0fb40e5d02f827f925b7702ed6f64fadce2 drm-tip: 2017y-02m-27d-22h-04m-19s UTC 
integration manifest
d382435 drm/i915: Consolidate reporting of "missed breadcrumbs"

== Logs ==

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

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Suppress context restore w/a when using MI_RESTORE_INHIBIT

[Chris Wilson]

On Fri, Feb 24, 2017 at 12:45:54PM +0200, Mika Kuoppala wrote:
> Chris Wilson  writes:
> 
> > If we are setting the context and do inhibit the restoration from the
> > context image, also forgo applying the set-context w/a.
> >
> > Signed-off-by: Chris Wilson 
> > ---
> >  drivers/gpu/drm/i915/i915_gem_context.c | 12 ++--
> >  1 file changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
> > b/drivers/gpu/drm/i915/i915_gem_context.c
> > index baceca14f5e0..25e8db73542a 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> > @@ -577,17 +577,17 @@ void i915_gem_context_close(struct drm_device *dev, 
> > struct drm_file *file)
> >  }
> >  
> >  static inline int
> > -mi_set_context(struct drm_i915_gem_request *req, u32 hw_flags)
> > +mi_set_context(struct drm_i915_gem_request *req, u32 flags)
> >  {
> > struct drm_i915_private *dev_priv = req->i915;
> > struct intel_engine_cs *engine = req->engine;
> > enum intel_engine_id id;
> > -   u32 *cs, flags = hw_flags | MI_MM_SPACE_GTT;
> > const int num_rings =
> > /* Use an extended w/a on ivb+ if signalling from other rings */
> > i915.semaphores ?
> > INTEL_INFO(dev_priv)->num_rings - 1 :
> > 0;
> > +   u32 *cs;
> > int len;
> >  
> > /* These flags are for resource streamer on HSW+ */
> > @@ -595,10 +595,10 @@ mi_set_context(struct drm_i915_gem_request *req, u32 
> > hw_flags)
> > flags |= (HSW_MI_RS_SAVE_STATE_EN | HSW_MI_RS_RESTORE_STATE_EN);
> > else if (INTEL_GEN(dev_priv) < 8)
> > flags |= (MI_SAVE_EXT_STATE_EN | MI_RESTORE_EXT_STATE_EN);
> > -
> > +   flags |= MI_MM_SPACE_GTT;
> >  
> > len = 4;
> > -   if (INTEL_GEN(dev_priv) >= 7)
> > +   if (INTEL_GEN(dev_priv) >= 7 && !(flags & MI_RESTORE_INHIBIT))
> 
> If we are restoring from the context image, we dont need the
> workarounds. So should this be 

I merged up to the previous patch as we ran into an uncertainity as to
whether some of the w/a applied to restore or to save.

The next patch is still interesting, but merits some soak testing to see
if cures the last full-ppgtt corruption on hsw.
-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] drm/i915: Consolidate reporting of "missed breadcrumbs"

[Chris Wilson]

Move the setting of gpu_error->missed_irq_ring bit to a common function
so that we can get the debug logging for either path.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_breadcrumbs.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index 7c7867d65a39..695ecec52d50 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -59,6 +59,16 @@ static unsigned long wait_timeout(void)
return round_jiffies_up(jiffies + DRM_I915_HANGCHECK_JIFFIES);
 }
 
+static void missed_breadcrumb(struct intel_engine_cs *engine)
+{
+   DRM_DEBUG_DRIVER("%s missed breadcrumb, irq posted? %s\n",
+engine->name,
+yesno(test_bit(ENGINE_IRQ_BREADCRUMB,
+   >irq_posted)));
+
+   set_bit(engine->id, >i915->gpu_error.missed_irq_rings);
+}
+
 static void intel_breadcrumbs_hangcheck(unsigned long data)
 {
struct intel_engine_cs *engine = (struct intel_engine_cs *)data;
@@ -86,8 +96,7 @@ static void intel_breadcrumbs_hangcheck(unsigned long data)
 * DRM_I915_HANGCHECK_JIFFIES [1.5s]!
 */
if (intel_engine_wakeup(engine) & ENGINE_WAKEUP_ASLEEP) {
-   DRM_DEBUG("Hangcheck timer elapsed... %s idle\n", engine->name);
-   set_bit(engine->id, >i915->gpu_error.missed_irq_rings);
+   missed_breadcrumb(engine);
mod_timer(>breadcrumbs.fake_irq, jiffies + 1);
} else {
mod_timer(>hangcheck, wait_timeout());
@@ -180,7 +189,7 @@ void intel_engine_disarm_breadcrumbs(struct intel_engine_cs 
*engine)
 * completion.
 */
if (__intel_breadcrumbs_wakeup(b) & ENGINE_WAKEUP_ASLEEP)
-   set_bit(engine->id, >i915->gpu_error.missed_irq_rings);
+   missed_breadcrumb(engine);
 
__intel_engine_disarm_breadcrumbs(engine);
 
-- 
2.11.0

___
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/i915: Avoiding recursing on ww_mutex inside shrinker

[Patchwork]

== Series Details ==

Series: drm/i915: Avoiding recursing on ww_mutex inside shrinker
URL   : https://patchwork.freedesktop.org/series/20328/
State : failure

== Summary ==

Series 20328v1 drm/i915: Avoiding recursing on ww_mutex inside shrinker
https://patchwork.freedesktop.org/api/1.0/series/20328/revisions/1/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
pass   -> FAIL   (fi-snb-2600)

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:108  pass:95   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:1   skip:29 

1a8bd0fb40e5d02f827f925b7702ed6f64fadce2 drm-tip: 2017y-02m-27d-22h-04m-19s UTC 
integration manifest
56e84b1 drm/i915: Avoiding recursing on ww_mutex inside shrinker

== Logs ==

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

Re: [Intel-gfx] [PATCH] ACPI / bus: Introduce a list of ids for "always present" devices

[Takashi Iwai]

On Mon, 27 Feb 2017 22:27:58 +0100,
Rafael J. Wysocki wrote:
> 
> On Mon, Feb 27, 2017 at 3:40 PM, Takashi Iwai  wrote:
> > On Mon, 27 Feb 2017 15:25:32 +0100,
> > Hans de Goede wrote:
> >>
> >> Hi,
> >>
> >> On 27-02-17 14:30, Rafael J. Wysocki wrote:
> >> > +Mika & Andy
> >> >
> >> > On Saturday, February 25, 2017 07:23:28 PM Hans de Goede wrote:
> >> >> Several cherrytrail devices (all of which ship with windows 10) hide the
> >> >> lpss pwm controller in ACPI, typically the _STA method looks like this:
> >> >>
> >> >> Method (_STA, 0, NotSerialized)  // _STA: Status
> >> >> {
> >> >> If (OSID == One)
> >> >> {
> >> >> Return (Zero)
> >> >> }
> >> >>
> >> >> Return (0x0F)
> >> >> }
> >> >>
> >> >> Where OSID is some dark magic seen in all cherrytrail ACPI tables making
> >> >> the machine behave differently depending on which OS it *thinks* it is
> >> >> booting, this gets set in a number of ways which we cannot control, on
> >> >> some newer machines it simple hardcoded to "One" aka win10.
> >> >>
> >> >> This causes the PWM controller to get hidden, which means Linux cannot
> >> >> control the backlight level on cht based tablets / laptops.
> >> >>
> >> >> Since loading the driver for this does no harm (the only in kernel user
> >> >> of it is the i915 driver, which will only use it when it needs it), this
> >> >> commit makes acpi_bus_get_status() always set status to ACPI_STA_DEFAULT
> >> >> for the 80862288 device, fixing the lack of backlight control.
> >> >>
> >> >> Signed-off-by: Hans de Goede 
> >> >> ---
> >> >>  drivers/acpi/bus.c | 25 +
> >> >>  1 file changed, 25 insertions(+)
> >> >>
> >> >> diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
> >> >> index 95855cb..483d4d0 100644
> >> >> --- a/drivers/acpi/bus.c
> >> >> +++ b/drivers/acpi/bus.c
> >> >> @@ -109,11 +109,36 @@ acpi_status 
> >> >> acpi_bus_get_status_handle(acpi_handle handle,
> >> >>return status;
> >> >>  }
> >> >>
> >> >> +/*
> >> >> + * Some ACPI devices are hidden (status == 0x0) in recent BIOS-es 
> >> >> because
> >> >> + * some recent windows drivers bind to one device but poke at multiple
> >> >> + * devices at the same time, so the others get hidden.
> >> >> + * We work around this by always reporting ACPI_STA_DEFAULT for these
> >> >> + * devices. Note this MUST only be done for devices where this is safe.
> >> >> + */
> >> >> +static const struct acpi_device_id always_present_device_ids[] = {
> >> >> +  /*
> >> >> +   * Cherrytrail pwm directly poked by GPU driver in win10,
> >> >> +   * but Linux uses a separate pwm driver, harmless if not used.
> >> >> +   */
> >> >> +  { "80862288", },
> >> >> +  { }
> >> >> +};
> >> >> +
> >> >>  int acpi_bus_get_status(struct acpi_device *device)
> >> >>  {
> >> >>acpi_status status;
> >> >>unsigned long long sta;
> >> >>
> >> >> +  /* acpi_match_device_ids checks status, so start with default */
> >> >> +  acpi_set_device_status(device, ACPI_STA_DEFAULT);
> >> >
> >> > This shouldn't be done in a "get" routine.
> >>
> >> With this you mean the acpi_match_device_ids() check I assume ?
> >> (acpi_bus_get_status already calls acpi_set_device_status())
> >>
> >> > Ideally, a scan handler should do that or similar.
> >>
> >> The problem is that drivers/acpi/scan.c: acpi_bus_attach()
> >> calls acpi_bus_get_status() and if it does not set
> >> the status to present acpi_bus_attach() exits without bothering
> >> with attaching scan handlers, which is why I ended up doing this
> >> here.
> >
> > Oh, this is interesting, please let me join to the party.
> >
> > We've hit a similar problem, but for other one: namely, it's INT0002
> > that is found on a few CHT devices.  It's never bound properly by a
> > similar reason, where _STA is always zero on Linux:
> >
> > Method (_STA, 0, NotSerialized)  // _STA: Status
> > {
> > If (SOCS <= 0x04)
> > {
> > Return (0x0F)
> > }
> > Else
> > {
> > Return (Zero)
> > }
> > }
> >
> > The device is supposed to be a "virtual GPIO" stuff, and the driver
> > hasn't been upstreamed from Intel.  Due to the lack of this driver
> > (and it's binding), the machine gets spurious IRQ#9 after the PM
> > resume, and it locks up at the second time of PM.
> 
> Well, the solution here seems to be to acquire the missing driver
> instead of adding quirks to the ACPI core.

The driver is available (not upstreamed, though), but it's not bound
due to _STA above.  That's why I'm interested in this thread.


thanks,

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

[Intel-gfx] [PATCH] drm/i915: Avoiding recursing on ww_mutex inside shrinker

[Chris Wilson]

We have to avoid taking ww_mutex inside the shrinker as we use it as a
plain mutex type and so need to avoid recursive deadlocks:

[  602.771969] =
[  602.771970] [ INFO: inconsistent lock state ]
[  602.771973] 4.10.0gpudebug+ #122 Not tainted
[  602.771974] -
[  602.771975] inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-W} usage.
[  602.771978] kswapd0/40 [HC0[0]:SC0[0]:HE1:SE1] takes:
[  602.771979]  (reservation_ww_class_mutex){+.+.?.}, at: [] 
i915_gem_object_wait+0x39a/0x410 [i915]
[  602.772020] {RECLAIM_FS-ON-W} state was registered at:
[  602.772024]   mark_held_locks+0x76/0x90
[  602.772026]   lockdep_trace_alloc+0xb8/0xc0
[  602.772028]   __kmalloc_track_caller+0x5d/0x130
[  602.772031]   krealloc+0x89/0xb0
[  602.772033]   reservation_object_reserve_shared+0xaf/0xd0
[  602.772055]   i915_gem_do_execbuffer.isra.35+0x1413/0x18b0 [i915]
[  602.772075]   i915_gem_execbuffer2+0x10e/0x1d0 [i915]
[  602.772078]   drm_ioctl+0x291/0x480
[  602.772079]   do_vfs_ioctl+0x695/0x6f0
[  602.772081]   SyS_ioctl+0x3c/0x70
[  602.772084]   entry_SYSCALL_64_fastpath+0x18/0xad
[  602.772085] irq event stamp: 5197423
[  602.772088] hardirqs last  enabled at (5197423): [] 
kfree+0xdd/0x170
[  602.772091] hardirqs last disabled at (5197422): [] 
kfree+0xb9/0x170
[  602.772095] softirqs last  enabled at (5190992): [] 
__do_softirq+0x221/0x280
[  602.772097] softirqs last disabled at (5190575): [] 
irq_exit+0x64/0xc0
[  602.772099]
   other info that might help us debug this:
[  602.772100]  Possible unsafe locking scenario:

[  602.772101]CPU0
[  602.772101]
[  602.772102]   lock(reservation_ww_class_mutex);
[  602.772104]   
[  602.772105] lock(reservation_ww_class_mutex);
[  602.772107]
*** DEADLOCK ***

[  602.772109] 2 locks held by kswapd0/40:
[  602.772110]  #0:  (shrinker_rwsem){..}, at: [] 
shrink_slab.constprop.62+0x35/0x280
[  602.772116]  #1:  (>struct_mutex){+.+.+.}, at: [] 
i915_gem_shrinker_lock+0x27/0x60 [i915]
[  602.772141]
   stack backtrace:
[  602.772144] CPU: 2 PID: 40 Comm: kswapd0 Not tainted 4.10.0gpudebug+ #122
[  602.772145] Hardware name: LENOVO 42433ZG/42433ZG, BIOS 8AET64WW (1.44 ) 
07/26/2013
[  602.772147] Call Trace:
[  602.772151]  dump_stack+0x68/0xa1
[  602.772153]  print_usage_bug+0x1d4/0x1f0
[  602.772155]  mark_lock+0x390/0x530
[  602.772157]  ? print_irq_inversion_bug+0x200/0x200
[  602.772159]  __lock_acquire+0x405/0x1260
[  602.772181]  ? i915_gem_object_wait+0x39a/0x410 [i915]
[  602.772183]  lock_acquire+0x60/0x80
[  602.772205]  ? i915_gem_object_wait+0x39a/0x410 [i915]
[  602.772207]  mutex_lock_nested+0x69/0x760
[  602.772229]  ? i915_gem_object_wait+0x39a/0x410 [i915]
[  602.772231]  ? kfree+0xdd/0x170
[  602.772253]  ? i915_gem_object_wait+0x163/0x410 [i915]
[  602.772255]  ? trace_hardirqs_on_caller+0x18d/0x1c0
[  602.772256]  ? trace_hardirqs_on+0xd/0x10
[  602.772278]  i915_gem_object_wait+0x39a/0x410 [i915]
[  602.772300]  i915_gem_object_unbind+0x5e/0x130 [i915]
[  602.772323]  i915_gem_shrink+0x22d/0x3d0 [i915]
[  602.772347]  i915_gem_shrinker_scan+0x3f/0x80 [i915]
[  602.772349]  shrink_slab.constprop.62+0x1ad/0x280
[  602.772352]  shrink_node+0x52/0x80
[  602.772355]  kswapd+0x427/0x5c0
[  602.772358]  kthread+0x122/0x130
[  602.772360]  ? try_to_free_pages+0x270/0x270
[  602.772362]  ? kthread_stop+0x70/0x70
[  602.772365]  ret_from_fork+0x2e/0x40

Reported-by: Jan Nordholz 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99977#c10
Fixes: e54ca9774777 ("drm/i915: Remove completed fences after a wait")
Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_gem.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 4c645f8ab05d..68d1a59ec4e6 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -466,10 +466,11 @@ i915_gem_object_wait_reservation(struct 
reservation_object *resv,
dma_fence_put(excl);
 
if (prune_fences && !__read_seqcount_retry(>seq, seq)) {
-   reservation_object_lock(resv, NULL);
-   if (!__read_seqcount_retry(>seq, seq))
-   reservation_object_add_excl_fence(resv, NULL);
-   reservation_object_unlock(resv);
+   if (reservation_object_trylock(resv)) {
+   if (!__read_seqcount_retry(>seq, seq))
+   reservation_object_add_excl_fence(resv, NULL);
+   reservation_object_unlock(resv);
+   }
}
 
return timeout;
-- 
2.11.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/4] drm/i915: Report both waiters and success from intel_engine_wakeup()

[Chris Wilson]

On Mon, Feb 27, 2017 at 09:22:31PM -, Patchwork wrote:
> == Series Details ==
> 
> Series: series starting with [CI,1/4] drm/i915: Report both waiters and 
> success from intel_engine_wakeup()
> URL   : https://patchwork.freedesktop.org/series/20325/
> State : success
> 
> == Summary ==
> 
> Series 20325v1 Series without cover letter
> https://patchwork.freedesktop.org/api/1.0/series/20325/revisions/1/mbox/
> 
> Test kms_pipe_crc_basic:
> Subgroup suspend-read-crc-pipe-b:
> dmesg-warn -> PASS   (fi-skl-6700k)

Pushed this for its minor improvement to execlists inter-engine latency
and planning for enabling guc scheduling (using emulation).

Thanks for the review,
-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 resend 11/15] drm/i915/dsi: Group MIPI_SEQ_BACKLIGHT_ON/OFF with panel_[en|dis]able_backlight

[Hans de Goede]

Hi,

On 27-02-17 18:06, Bob Paauwe wrote:

On Sat, 25 Feb 2017 11:37:50 +0100
Hans de Goede  wrote:


Hi,

On 24-02-17 18:00, Bob Paauwe wrote:

On Mon, 20 Feb 2017 15:08:41 +0100
Hans de Goede  wrote:


Execute the MIPI_SEQ_BACKLIGHT_ON/OFF VBT sequences at the same time as
we call intel_panel_enable_backlight() / intel_panel_disable_backlight().

Signed-off-by: Hans de Goede 


I'm not sure that the added comments are necessary.  Maybe if there was
some explanation for why we're using two different mechanisms to
enable/disable backlight instead.


That assumes I know why there are 2 mechanisms of I have to guess it
is because on some boards only one of the mechanisms works, but that
is just a guess. Just calling the VBT sequence should be enough on
(most?) boards.

Regards,

Hans


I don't think I can describe why we have two mechanisms so just
dropping the comment would be my preference at this point.


Ok, done for v2 of the patch-set I will go through your other comments
tomorrow and then send a v2.

Regards,

Hans



It may be that calling the intel_panel_enable_backlight() will make
sure the sysfs entries are correct while the VBT sequence simply
modifies the hardware.

Possibly a good solution would be to enhance the code that executes the
VBT sequence to also call the intel_panel_enable_backlight(), but
that's not something to change here.






Reviewed-by: Bob Paauwe 


---
 drivers/gpu/drm/i915/intel_dsi.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 8408f59..a8d0948 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -687,12 +687,13 @@ static void intel_dsi_pre_enable(struct intel_encoder 
*encoder,
msleep(100);

intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_ON);
-   intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_ON);

intel_dsi_port_enable(encoder);
}

+   /* Enable backlight, both pwm and VBT */
intel_panel_enable_backlight() (intel_dsi->attached_connector);
+   intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_ON);
 }

 static void intel_dsi_enable_nop(struct intel_encoder *encoder,
@@ -718,6 +719,8 @@ static void intel_dsi_pre_disable(struct intel_encoder 
*encoder,

DRM_DEBUG_KMS("\n");

+   /* Disable backlight, both VBT and pwm */
+   intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_OFF);
intel_panel_disable_backlight(intel_dsi->attached_connector);

/*
@@ -762,7 +765,6 @@ static void intel_dsi_post_disable(struct intel_encoder 
*encoder,
 * if disable packets are sent before sending shutdown packet then in
 * some next enable sequence send turn on packet error is observed
 */
-   intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_OFF);
intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_OFF);

/* Transition to LP-00 */









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

Re: [Intel-gfx] [PATCH] ACPI / bus: Introduce a list of ids for "always present" devices

[Rafael J. Wysocki]

On Mon, Feb 27, 2017 at 10:58 PM, Hans de Goede  wrote:
> Hi,
>
>
> On 27-02-17 22:49, Rafael J. Wysocki wrote:
>>
>> On Mon, Feb 27, 2017 at 10:29 PM, Hans de Goede 
>> wrote:
>>>
>>> Hi,
>>>
>>>
>>> On 27-02-17 22:25, Rafael J. Wysocki wrote:


 On Mon, Feb 27, 2017 at 3:25 PM, Hans de Goede 
 wrote:
>
>
> Hi,
>
>
> On 27-02-17 14:30, Rafael J. Wysocki wrote:
>>
>>
>>
>> +Mika & Andy
>>
>> On Saturday, February 25, 2017 07:23:28 PM Hans de Goede wrote:
>>>
>>>
>>>
>>> Several cherrytrail devices (all of which ship with windows 10) hide
>>> the
>>> lpss pwm controller in ACPI, typically the _STA method looks like
>>> this:
>>>
>>> Method (_STA, 0, NotSerialized)  // _STA: Status
>>> {
>>> If (OSID == One)
>>> {
>>> Return (Zero)
>>> }
>>>
>>> Return (0x0F)
>>> }
>>>
>>> Where OSID is some dark magic seen in all cherrytrail ACPI tables
>>> making
>>> the machine behave differently depending on which OS it *thinks* it
>>> is
>>> booting, this gets set in a number of ways which we cannot control,
>>> on
>>> some newer machines it simple hardcoded to "One" aka win10.
>>>
>>> This causes the PWM controller to get hidden, which means Linux
>>> cannot
>>> control the backlight level on cht based tablets / laptops.
>>>
>>> Since loading the driver for this does no harm (the only in kernel
>>> user
>>> of it is the i915 driver, which will only use it when it needs it),
>>> this
>>> commit makes acpi_bus_get_status() always set status to
>>> ACPI_STA_DEFAULT
>>> for the 80862288 device, fixing the lack of backlight control.
>>>
>>> Signed-off-by: Hans de Goede 
>>> ---
>>>  drivers/acpi/bus.c | 25 +
>>>  1 file changed, 25 insertions(+)
>>>
>>> diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
>>> index 95855cb..483d4d0 100644
>>> --- a/drivers/acpi/bus.c
>>> +++ b/drivers/acpi/bus.c
>>> @@ -109,11 +109,36 @@ acpi_status
>>> acpi_bus_get_status_handle(acpi_handle
>>> handle,
>>> return status;
>>>  }
>>>
>>> +/*
>>> + * Some ACPI devices are hidden (status == 0x0) in recent BIOS-es
>>> because
>>> + * some recent windows drivers bind to one device but poke at
>>> multiple
>>> + * devices at the same time, so the others get hidden.
>>> + * We work around this by always reporting ACPI_STA_DEFAULT for
>>> these
>>> + * devices. Note this MUST only be done for devices where this is
>>> safe.
>>> + */
>>> +static const struct acpi_device_id always_present_device_ids[] = {
>>> +   /*
>>> +* Cherrytrail pwm directly poked by GPU driver in win10,
>>> +* but Linux uses a separate pwm driver, harmless if not
>>> used.
>>> +*/
>>> +   { "80862288", },
>>> +   { }
>>> +};
>>> +
>>>  int acpi_bus_get_status(struct acpi_device *device)
>>>  {
>>> acpi_status status;
>>> unsigned long long sta;
>>>
>>> +   /* acpi_match_device_ids checks status, so start with default
>>> */
>>> +   acpi_set_device_status(device, ACPI_STA_DEFAULT);
>>
>>
>>
>>
>> This shouldn't be done in a "get" routine.
>
>
>
>
> With this you mean the acpi_match_device_ids() check I assume ?
> (acpi_bus_get_status already calls acpi_set_device_status())



 Yes, the device ID check.

>> Ideally, a scan handler should do that or similar.
>
>
>
>
> The problem is that drivers/acpi/scan.c: acpi_bus_attach()
> calls acpi_bus_get_status() and if it does not set
> the status to present acpi_bus_attach() exits without bothering
> with attaching scan handlers, which is why I ended up doing this
> here.



 Fair enough.

 Two problems with this approach.

 One is that it doesn't prevent _STA from being evaluated as
 acpi_bus_get_status_handle() is called directly from a couple of
 places.
>>>
>>>
>>> Yes I noticed that, but that is not a problem for this
>>> (and I would assume most) devices. Intervening directly
>>> in acpi_bus_get_status_handle is harder as there is no
>>> access to the hid there.
>>
>>
>> But if you modify acpi_set_device_status(), that should make it
>> consistent AFAICS.
>>
>> And this is just a quirk for devices where _STA is known to return
>> garbage sometimes and I'd call it a quirk openly.
>
>
> Ok, currently acpi_set_device_status() is an inline function in
> include/acpi/acpi_bus.h. If I understand you correctly you want me
> to uninline it and have a table with quirks which specify 

Re: [Intel-gfx] [PATCH] ACPI / bus: Introduce a list of ids for "always present" devices

[Hans de Goede]

Hi,

On 27-02-17 22:49, Rafael J. Wysocki wrote:

On Mon, Feb 27, 2017 at 10:29 PM, Hans de Goede  wrote:

Hi,


On 27-02-17 22:25, Rafael J. Wysocki wrote:


On Mon, Feb 27, 2017 at 3:25 PM, Hans de Goede 
wrote:


Hi,


On 27-02-17 14:30, Rafael J. Wysocki wrote:



+Mika & Andy

On Saturday, February 25, 2017 07:23:28 PM Hans de Goede wrote:



Several cherrytrail devices (all of which ship with windows 10) hide
the
lpss pwm controller in ACPI, typically the _STA method looks like this:

Method (_STA, 0, NotSerialized)  // _STA: Status
{
If (OSID == One)
{
Return (Zero)
}

Return (0x0F)
}

Where OSID is some dark magic seen in all cherrytrail ACPI tables
making
the machine behave differently depending on which OS it *thinks* it is
booting, this gets set in a number of ways which we cannot control, on
some newer machines it simple hardcoded to "One" aka win10.

This causes the PWM controller to get hidden, which means Linux cannot
control the backlight level on cht based tablets / laptops.

Since loading the driver for this does no harm (the only in kernel user
of it is the i915 driver, which will only use it when it needs it),
this
commit makes acpi_bus_get_status() always set status to
ACPI_STA_DEFAULT
for the 80862288 device, fixing the lack of backlight control.

Signed-off-by: Hans de Goede 
---
 drivers/acpi/bus.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 95855cb..483d4d0 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -109,11 +109,36 @@ acpi_status
acpi_bus_get_status_handle(acpi_handle
handle,
return status;
 }

+/*
+ * Some ACPI devices are hidden (status == 0x0) in recent BIOS-es
because
+ * some recent windows drivers bind to one device but poke at multiple
+ * devices at the same time, so the others get hidden.
+ * We work around this by always reporting ACPI_STA_DEFAULT for these
+ * devices. Note this MUST only be done for devices where this is
safe.
+ */
+static const struct acpi_device_id always_present_device_ids[] = {
+   /*
+* Cherrytrail pwm directly poked by GPU driver in win10,
+* but Linux uses a separate pwm driver, harmless if not used.
+*/
+   { "80862288", },
+   { }
+};
+
 int acpi_bus_get_status(struct acpi_device *device)
 {
acpi_status status;
unsigned long long sta;

+   /* acpi_match_device_ids checks status, so start with default
*/
+   acpi_set_device_status(device, ACPI_STA_DEFAULT);




This shouldn't be done in a "get" routine.




With this you mean the acpi_match_device_ids() check I assume ?
(acpi_bus_get_status already calls acpi_set_device_status())



Yes, the device ID check.


Ideally, a scan handler should do that or similar.




The problem is that drivers/acpi/scan.c: acpi_bus_attach()
calls acpi_bus_get_status() and if it does not set
the status to present acpi_bus_attach() exits without bothering
with attaching scan handlers, which is why I ended up doing this
here.



Fair enough.

Two problems with this approach.

One is that it doesn't prevent _STA from being evaluated as
acpi_bus_get_status_handle() is called directly from a couple of
places.


Yes I noticed that, but that is not a problem for this
(and I would assume most) devices. Intervening directly
in acpi_bus_get_status_handle is harder as there is no
access to the hid there.


But if you modify acpi_set_device_status(), that should make it
consistent AFAICS.

And this is just a quirk for devices where _STA is known to return
garbage sometimes and I'd call it a quirk openly.


Ok, currently acpi_set_device_status() is an inline function in
include/acpi/acpi_bus.h. If I understand you correctly you want me
to uninline it and have a table with quirks which specify an override
value to apply for certain acpi_ids in the uninlined version, correct ?

Or is there some existing quirk mechanism I should tie into ?

Regards,

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

Re: [Intel-gfx] [PATCH] ACPI / bus: Introduce a list of ids for "always present" devices

[Rafael J. Wysocki]

On Mon, Feb 27, 2017 at 10:29 PM, Hans de Goede  wrote:
> Hi,
>
>
> On 27-02-17 22:25, Rafael J. Wysocki wrote:
>>
>> On Mon, Feb 27, 2017 at 3:25 PM, Hans de Goede 
>> wrote:
>>>
>>> Hi,
>>>
>>>
>>> On 27-02-17 14:30, Rafael J. Wysocki wrote:


 +Mika & Andy

 On Saturday, February 25, 2017 07:23:28 PM Hans de Goede wrote:
>
>
> Several cherrytrail devices (all of which ship with windows 10) hide
> the
> lpss pwm controller in ACPI, typically the _STA method looks like this:
>
> Method (_STA, 0, NotSerialized)  // _STA: Status
> {
> If (OSID == One)
> {
> Return (Zero)
> }
>
> Return (0x0F)
> }
>
> Where OSID is some dark magic seen in all cherrytrail ACPI tables
> making
> the machine behave differently depending on which OS it *thinks* it is
> booting, this gets set in a number of ways which we cannot control, on
> some newer machines it simple hardcoded to "One" aka win10.
>
> This causes the PWM controller to get hidden, which means Linux cannot
> control the backlight level on cht based tablets / laptops.
>
> Since loading the driver for this does no harm (the only in kernel user
> of it is the i915 driver, which will only use it when it needs it),
> this
> commit makes acpi_bus_get_status() always set status to
> ACPI_STA_DEFAULT
> for the 80862288 device, fixing the lack of backlight control.
>
> Signed-off-by: Hans de Goede 
> ---
>  drivers/acpi/bus.c | 25 +
>  1 file changed, 25 insertions(+)
>
> diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
> index 95855cb..483d4d0 100644
> --- a/drivers/acpi/bus.c
> +++ b/drivers/acpi/bus.c
> @@ -109,11 +109,36 @@ acpi_status
> acpi_bus_get_status_handle(acpi_handle
> handle,
> return status;
>  }
>
> +/*
> + * Some ACPI devices are hidden (status == 0x0) in recent BIOS-es
> because
> + * some recent windows drivers bind to one device but poke at multiple
> + * devices at the same time, so the others get hidden.
> + * We work around this by always reporting ACPI_STA_DEFAULT for these
> + * devices. Note this MUST only be done for devices where this is
> safe.
> + */
> +static const struct acpi_device_id always_present_device_ids[] = {
> +   /*
> +* Cherrytrail pwm directly poked by GPU driver in win10,
> +* but Linux uses a separate pwm driver, harmless if not used.
> +*/
> +   { "80862288", },
> +   { }
> +};
> +
>  int acpi_bus_get_status(struct acpi_device *device)
>  {
> acpi_status status;
> unsigned long long sta;
>
> +   /* acpi_match_device_ids checks status, so start with default
> */
> +   acpi_set_device_status(device, ACPI_STA_DEFAULT);



 This shouldn't be done in a "get" routine.
>>>
>>>
>>>
>>> With this you mean the acpi_match_device_ids() check I assume ?
>>> (acpi_bus_get_status already calls acpi_set_device_status())
>>
>>
>> Yes, the device ID check.
>>
 Ideally, a scan handler should do that or similar.
>>>
>>>
>>>
>>> The problem is that drivers/acpi/scan.c: acpi_bus_attach()
>>> calls acpi_bus_get_status() and if it does not set
>>> the status to present acpi_bus_attach() exits without bothering
>>> with attaching scan handlers, which is why I ended up doing this
>>> here.
>>
>>
>> Fair enough.
>>
>> Two problems with this approach.
>>
>> One is that it doesn't prevent _STA from being evaluated as
>> acpi_bus_get_status_handle() is called directly from a couple of
>> places.
>
> Yes I noticed that, but that is not a problem for this
> (and I would assume most) devices. Intervening directly
> in acpi_bus_get_status_handle is harder as there is no
> access to the hid there.

But if you modify acpi_set_device_status(), that should make it
consistent AFAICS.

And this is just a quirk for devices where _STA is known to return
garbage sometimes and I'd call it a quirk openly.

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

Re: [Intel-gfx] [PATCH] ACPI / bus: Introduce a list of ids for "always present" devices

[Hans de Goede]

Hi,

On 27-02-17 22:25, Rafael J. Wysocki wrote:

On Mon, Feb 27, 2017 at 3:25 PM, Hans de Goede  wrote:

Hi,


On 27-02-17 14:30, Rafael J. Wysocki wrote:


+Mika & Andy

On Saturday, February 25, 2017 07:23:28 PM Hans de Goede wrote:


Several cherrytrail devices (all of which ship with windows 10) hide the
lpss pwm controller in ACPI, typically the _STA method looks like this:

Method (_STA, 0, NotSerialized)  // _STA: Status
{
If (OSID == One)
{
Return (Zero)
}

Return (0x0F)
}

Where OSID is some dark magic seen in all cherrytrail ACPI tables making
the machine behave differently depending on which OS it *thinks* it is
booting, this gets set in a number of ways which we cannot control, on
some newer machines it simple hardcoded to "One" aka win10.

This causes the PWM controller to get hidden, which means Linux cannot
control the backlight level on cht based tablets / laptops.

Since loading the driver for this does no harm (the only in kernel user
of it is the i915 driver, which will only use it when it needs it), this
commit makes acpi_bus_get_status() always set status to ACPI_STA_DEFAULT
for the 80862288 device, fixing the lack of backlight control.

Signed-off-by: Hans de Goede 
---
 drivers/acpi/bus.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 95855cb..483d4d0 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -109,11 +109,36 @@ acpi_status acpi_bus_get_status_handle(acpi_handle
handle,
return status;
 }

+/*
+ * Some ACPI devices are hidden (status == 0x0) in recent BIOS-es
because
+ * some recent windows drivers bind to one device but poke at multiple
+ * devices at the same time, so the others get hidden.
+ * We work around this by always reporting ACPI_STA_DEFAULT for these
+ * devices. Note this MUST only be done for devices where this is safe.
+ */
+static const struct acpi_device_id always_present_device_ids[] = {
+   /*
+* Cherrytrail pwm directly poked by GPU driver in win10,
+* but Linux uses a separate pwm driver, harmless if not used.
+*/
+   { "80862288", },
+   { }
+};
+
 int acpi_bus_get_status(struct acpi_device *device)
 {
acpi_status status;
unsigned long long sta;

+   /* acpi_match_device_ids checks status, so start with default */
+   acpi_set_device_status(device, ACPI_STA_DEFAULT);



This shouldn't be done in a "get" routine.



With this you mean the acpi_match_device_ids() check I assume ?
(acpi_bus_get_status already calls acpi_set_device_status())


Yes, the device ID check.


Ideally, a scan handler should do that or similar.



The problem is that drivers/acpi/scan.c: acpi_bus_attach()
calls acpi_bus_get_status() and if it does not set
the status to present acpi_bus_attach() exits without bothering
with attaching scan handlers, which is why I ended up doing this
here.


Fair enough.

Two problems with this approach.

One is that it doesn't prevent _STA from being evaluated as
acpi_bus_get_status_handle() is called directly from a couple of
places.


Yes I noticed that, but that is not a problem for this
(and I would assume most) devices. Intervening directly
in acpi_bus_get_status_handle is harder as there is no
access to the hid there.


Second, what if the same device ID is used on another system where
_STA actually works correctly for that device?


You mean where _STA shoul actually report 0 because the
device is really unused. That is why the comment above
the table says:

+ * devices. Note this MUST only be done for devices where this is safe.

In case of the device in question this will cause the pwm driver
to bind to it, but nothing will in turn bind to the pwm interface
so nothing will be done with it.

Regards,

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

Re: [Intel-gfx] [PATCH] ACPI / bus: Introduce a list of ids for "always present" devices

[Rafael J. Wysocki]

On Mon, Feb 27, 2017 at 3:40 PM, Takashi Iwai  wrote:
> On Mon, 27 Feb 2017 15:25:32 +0100,
> Hans de Goede wrote:
>>
>> Hi,
>>
>> On 27-02-17 14:30, Rafael J. Wysocki wrote:
>> > +Mika & Andy
>> >
>> > On Saturday, February 25, 2017 07:23:28 PM Hans de Goede wrote:
>> >> Several cherrytrail devices (all of which ship with windows 10) hide the
>> >> lpss pwm controller in ACPI, typically the _STA method looks like this:
>> >>
>> >> Method (_STA, 0, NotSerialized)  // _STA: Status
>> >> {
>> >> If (OSID == One)
>> >> {
>> >> Return (Zero)
>> >> }
>> >>
>> >> Return (0x0F)
>> >> }
>> >>
>> >> Where OSID is some dark magic seen in all cherrytrail ACPI tables making
>> >> the machine behave differently depending on which OS it *thinks* it is
>> >> booting, this gets set in a number of ways which we cannot control, on
>> >> some newer machines it simple hardcoded to "One" aka win10.
>> >>
>> >> This causes the PWM controller to get hidden, which means Linux cannot
>> >> control the backlight level on cht based tablets / laptops.
>> >>
>> >> Since loading the driver for this does no harm (the only in kernel user
>> >> of it is the i915 driver, which will only use it when it needs it), this
>> >> commit makes acpi_bus_get_status() always set status to ACPI_STA_DEFAULT
>> >> for the 80862288 device, fixing the lack of backlight control.
>> >>
>> >> Signed-off-by: Hans de Goede 
>> >> ---
>> >>  drivers/acpi/bus.c | 25 +
>> >>  1 file changed, 25 insertions(+)
>> >>
>> >> diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
>> >> index 95855cb..483d4d0 100644
>> >> --- a/drivers/acpi/bus.c
>> >> +++ b/drivers/acpi/bus.c
>> >> @@ -109,11 +109,36 @@ acpi_status acpi_bus_get_status_handle(acpi_handle 
>> >> handle,
>> >>return status;
>> >>  }
>> >>
>> >> +/*
>> >> + * Some ACPI devices are hidden (status == 0x0) in recent BIOS-es because
>> >> + * some recent windows drivers bind to one device but poke at multiple
>> >> + * devices at the same time, so the others get hidden.
>> >> + * We work around this by always reporting ACPI_STA_DEFAULT for these
>> >> + * devices. Note this MUST only be done for devices where this is safe.
>> >> + */
>> >> +static const struct acpi_device_id always_present_device_ids[] = {
>> >> +  /*
>> >> +   * Cherrytrail pwm directly poked by GPU driver in win10,
>> >> +   * but Linux uses a separate pwm driver, harmless if not used.
>> >> +   */
>> >> +  { "80862288", },
>> >> +  { }
>> >> +};
>> >> +
>> >>  int acpi_bus_get_status(struct acpi_device *device)
>> >>  {
>> >>acpi_status status;
>> >>unsigned long long sta;
>> >>
>> >> +  /* acpi_match_device_ids checks status, so start with default */
>> >> +  acpi_set_device_status(device, ACPI_STA_DEFAULT);
>> >
>> > This shouldn't be done in a "get" routine.
>>
>> With this you mean the acpi_match_device_ids() check I assume ?
>> (acpi_bus_get_status already calls acpi_set_device_status())
>>
>> > Ideally, a scan handler should do that or similar.
>>
>> The problem is that drivers/acpi/scan.c: acpi_bus_attach()
>> calls acpi_bus_get_status() and if it does not set
>> the status to present acpi_bus_attach() exits without bothering
>> with attaching scan handlers, which is why I ended up doing this
>> here.
>
> Oh, this is interesting, please let me join to the party.
>
> We've hit a similar problem, but for other one: namely, it's INT0002
> that is found on a few CHT devices.  It's never bound properly by a
> similar reason, where _STA is always zero on Linux:
>
> Method (_STA, 0, NotSerialized)  // _STA: Status
> {
> If (SOCS <= 0x04)
> {
> Return (0x0F)
> }
> Else
> {
> Return (Zero)
> }
> }
>
> The device is supposed to be a "virtual GPIO" stuff, and the driver
> hasn't been upstreamed from Intel.  Due to the lack of this driver
> (and it's binding), the machine gets spurious IRQ#9 after the PM
> resume, and it locks up at the second time of PM.

Well, the solution here seems to be to acquire the missing driver
instead of adding quirks to the ACPI core.

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

Re: [Intel-gfx] [PATCH] ACPI / bus: Introduce a list of ids for "always present" devices

[Rafael J. Wysocki]

On Mon, Feb 27, 2017 at 3:25 PM, Hans de Goede  wrote:
> Hi,
>
>
> On 27-02-17 14:30, Rafael J. Wysocki wrote:
>>
>> +Mika & Andy
>>
>> On Saturday, February 25, 2017 07:23:28 PM Hans de Goede wrote:
>>>
>>> Several cherrytrail devices (all of which ship with windows 10) hide the
>>> lpss pwm controller in ACPI, typically the _STA method looks like this:
>>>
>>> Method (_STA, 0, NotSerialized)  // _STA: Status
>>> {
>>> If (OSID == One)
>>> {
>>> Return (Zero)
>>> }
>>>
>>> Return (0x0F)
>>> }
>>>
>>> Where OSID is some dark magic seen in all cherrytrail ACPI tables making
>>> the machine behave differently depending on which OS it *thinks* it is
>>> booting, this gets set in a number of ways which we cannot control, on
>>> some newer machines it simple hardcoded to "One" aka win10.
>>>
>>> This causes the PWM controller to get hidden, which means Linux cannot
>>> control the backlight level on cht based tablets / laptops.
>>>
>>> Since loading the driver for this does no harm (the only in kernel user
>>> of it is the i915 driver, which will only use it when it needs it), this
>>> commit makes acpi_bus_get_status() always set status to ACPI_STA_DEFAULT
>>> for the 80862288 device, fixing the lack of backlight control.
>>>
>>> Signed-off-by: Hans de Goede 
>>> ---
>>>  drivers/acpi/bus.c | 25 +
>>>  1 file changed, 25 insertions(+)
>>>
>>> diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
>>> index 95855cb..483d4d0 100644
>>> --- a/drivers/acpi/bus.c
>>> +++ b/drivers/acpi/bus.c
>>> @@ -109,11 +109,36 @@ acpi_status acpi_bus_get_status_handle(acpi_handle
>>> handle,
>>> return status;
>>>  }
>>>
>>> +/*
>>> + * Some ACPI devices are hidden (status == 0x0) in recent BIOS-es
>>> because
>>> + * some recent windows drivers bind to one device but poke at multiple
>>> + * devices at the same time, so the others get hidden.
>>> + * We work around this by always reporting ACPI_STA_DEFAULT for these
>>> + * devices. Note this MUST only be done for devices where this is safe.
>>> + */
>>> +static const struct acpi_device_id always_present_device_ids[] = {
>>> +   /*
>>> +* Cherrytrail pwm directly poked by GPU driver in win10,
>>> +* but Linux uses a separate pwm driver, harmless if not used.
>>> +*/
>>> +   { "80862288", },
>>> +   { }
>>> +};
>>> +
>>>  int acpi_bus_get_status(struct acpi_device *device)
>>>  {
>>> acpi_status status;
>>> unsigned long long sta;
>>>
>>> +   /* acpi_match_device_ids checks status, so start with default */
>>> +   acpi_set_device_status(device, ACPI_STA_DEFAULT);
>>
>>
>> This shouldn't be done in a "get" routine.
>
>
> With this you mean the acpi_match_device_ids() check I assume ?
> (acpi_bus_get_status already calls acpi_set_device_status())

Yes, the device ID check.

>> Ideally, a scan handler should do that or similar.
>
>
> The problem is that drivers/acpi/scan.c: acpi_bus_attach()
> calls acpi_bus_get_status() and if it does not set
> the status to present acpi_bus_attach() exits without bothering
> with attaching scan handlers, which is why I ended up doing this
> here.

Fair enough.

Two problems with this approach.

One is that it doesn't prevent _STA from being evaluated as
acpi_bus_get_status_handle() is called directly from a couple of
places.

Second, what if the same device ID is used on another system where
_STA actually works correctly for that device?

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/4] drm/i915: Report both waiters and success from intel_engine_wakeup()

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/4] drm/i915: Report both waiters and success 
from intel_engine_wakeup()
URL   : https://patchwork.freedesktop.org/series/20325/
State : success

== Summary ==

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

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-skl-6700k)

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:108  pass:95   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29 

ea59cd057f94642a3e16f1059fc518faae14e0a8 drm-tip: 2017y-02m-27d-17h-23m-21s UTC 
integration manifest
8bf2e06 drm/i915: Delay disabling the user interrupt for breadcrumbs
e0b00ae drm/i915: Defer enabling hangcheck to the first fake breadcrumb 
interrupt
ae772f2 drm/i915: Signal first fence from irq handler if complete
66473ae drm/i915: Report both waiters and success from intel_engine_wakeup()

== Logs ==

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

[Intel-gfx] [CI 2/4] drm/i915: Signal first fence from irq handler if complete

[Chris Wilson]

As execlists and other non-semaphore multi-engine devices coordinate
between engines using interrupts, we can shave off a few 10s of
microsecond of scheduling latency by doing the fence signaling from the
interrupt as opposed to a RT kthread. (Realistically the delay adds
about 1% to an individual cross-engine workload.) We only signal the
first fence in order to limit the amount of work we move into the
interrupt handler. We also have to remember that our breadcrumbs may be
unordered with respect to the interrupt and so we still require the
waiter process to perform some heavyweight coherency fixups, as well as
traversing the tree of waiters.

v2: No need for early exit in irq handler - it breaks the flow between
patches and prevents the tracepoint
v3: Restore rcu hold across irq signaling of request

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.h  | 13 ++--
 drivers/gpu/drm/i915/i915_gem_request.c  |  2 +-
 drivers/gpu/drm/i915/i915_gem_request.h  |  2 ++
 drivers/gpu/drm/i915/i915_irq.c  | 36 +---
 drivers/gpu/drm/i915/intel_breadcrumbs.c | 32 +++-
 drivers/gpu/drm/i915/intel_ringbuffer.h  |  8 +++
 6 files changed, 54 insertions(+), 39 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9c5b3dd9f6f1..ca2c986a48cf 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -4073,9 +4073,9 @@ __i915_request_irq_complete(const struct 
drm_i915_gem_request *req)
 * is woken.
 */
if (engine->irq_seqno_barrier &&
-   rcu_access_pointer(engine->breadcrumbs.irq_seqno_bh) == current &&
test_and_clear_bit(ENGINE_IRQ_BREADCRUMB, >irq_posted)) {
-   struct task_struct *tsk;
+   struct intel_breadcrumbs *b = >breadcrumbs;
+   unsigned long flags;
 
/* The ordering of irq_posted versus applying the barrier
 * is crucial. The clearing of the current irq_posted must
@@ -4097,17 +4097,16 @@ __i915_request_irq_complete(const struct 
drm_i915_gem_request *req)
 * the seqno before we believe it coherent since they see
 * irq_posted == false but we are still running).
 */
-   rcu_read_lock();
-   tsk = rcu_dereference(engine->breadcrumbs.irq_seqno_bh);
-   if (tsk && tsk != current)
+   spin_lock_irqsave(>lock, flags);
+   if (b->first_wait && b->first_wait->tsk != current)
/* Note that if the bottom-half is changed as we
 * are sending the wake-up, the new bottom-half will
 * be woken by whomever made the change. We only have
 * to worry about when we steal the irq-posted for
 * ourself.
 */
-   wake_up_process(tsk);
-   rcu_read_unlock();
+   wake_up_process(b->first_wait->tsk);
+   spin_unlock_irqrestore(>lock, flags);
 
if (__i915_gem_request_completed(req, seqno))
return true;
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index fbfeb5f8d069..77c3ee7a3fd0 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -1083,7 +1083,7 @@ long i915_wait_request(struct drm_i915_gem_request *req,
if (flags & I915_WAIT_LOCKED)
add_wait_queue(errq, );
 
-   intel_wait_init();
+   intel_wait_init(, req);
 
 restart:
do {
diff --git a/drivers/gpu/drm/i915/i915_gem_request.h 
b/drivers/gpu/drm/i915/i915_gem_request.h
index 5f73d8c0a38a..0efee879df23 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.h
+++ b/drivers/gpu/drm/i915/i915_gem_request.h
@@ -32,10 +32,12 @@
 
 struct drm_file;
 struct drm_i915_gem_object;
+struct drm_i915_gem_request;
 
 struct intel_wait {
struct rb_node node;
struct task_struct *tsk;
+   struct drm_i915_gem_request *request;
u32 seqno;
 };
 
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index bc70e2c451b2..bc520ee8d6fe 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1033,12 +1033,42 @@ static void ironlake_rps_change_irq_handler(struct 
drm_i915_private *dev_priv)
 
 static void notify_ring(struct intel_engine_cs *engine)
 {
-   bool waiters;
+   struct drm_i915_gem_request *rq = NULL;
+   struct intel_wait *wait;
 
atomic_inc(>irq_count);
set_bit(ENGINE_IRQ_BREADCRUMB, >irq_posted);
-   waiters = intel_engine_wakeup(engine);
-   

[Intel-gfx] [CI 4/4] drm/i915: Delay disabling the user interrupt for breadcrumbs

[Chris Wilson]

A significant cost in setting up a wait is the overhead of enabling the
interrupt. As we disable the interrupt whenever the queue of waiters is
empty, if we are frequently waiting on alternating batches, we end up
re-enabling the interrupt on a frequent basis. We do want to disable the
interrupt during normal operations as under high load it may add several
thousand interrupts/s - we have been known in the past to occupy whole
cores with our interrupt handler after accidentally leaving user
interrupts enabled. As a compromise, leave the interrupt enabled until
the next IRQ, or the system is idle. This gives a small window for a
waiter to keep the interrupt active and not be delayed by having to
re-enable the interrupt.

v2: Restore hangcheck/missed-irq detection for continuations
v3: Be more careful restoring the hangcheck timer after reset
v4: Be more careful restoring the fake irq after reset (if required!)
v5: Redo changes to intel_engine_wakeup()
v6: Factor out __intel_engine_wakeup()
v7: Improve commentary for declaring a missed wakeup

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem.c  |   4 +-
 drivers/gpu/drm/i915/i915_irq.c  |   2 +
 drivers/gpu/drm/i915/intel_breadcrumbs.c | 176 ---
 drivers/gpu/drm/i915/intel_ringbuffer.h  |   7 +-
 4 files changed, 125 insertions(+), 64 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 01dbba3813c7..0ad080984877 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2988,8 +2988,10 @@ i915_gem_idle_work_handler(struct work_struct *work)
if (wait_for(intel_execlists_idle(dev_priv), 10))
DRM_ERROR("Timeout waiting for engines to idle\n");
 
-   for_each_engine(engine, dev_priv, id)
+   for_each_engine(engine, dev_priv, id) {
+   intel_engine_disarm_breadcrumbs(engine);
i915_gem_batch_pool_fini(>batch_pool);
+   }
 
GEM_BUG_ON(!dev_priv->gt.awake);
dev_priv->gt.awake = false;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index bc520ee8d6fe..ca8c7b22748e 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1060,6 +1060,8 @@ static void notify_ring(struct intel_engine_cs *engine)
rq = wait->request;
 
wake_up_process(wait->tsk);
+   } else {
+   __intel_engine_disarm_breadcrumbs(engine);
}
spin_unlock(>breadcrumbs.lock);
 
diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index 3855c8c39b35..7c7867d65a39 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -26,20 +26,30 @@
 
 #include "i915_drv.h"
 
-unsigned int intel_engine_wakeup(struct intel_engine_cs *engine)
+static unsigned int __intel_breadcrumbs_wakeup(struct intel_breadcrumbs *b)
 {
struct intel_wait *wait;
-   unsigned long flags;
unsigned int result = 0;
 
-   spin_lock_irqsave(>breadcrumbs.lock, flags);
-   wait = engine->breadcrumbs.first_wait;
+   wait = b->first_wait;
if (wait) {
result = ENGINE_WAKEUP_WAITER;
-   if (!wake_up_process(wait->tsk))
-   result |= ENGINE_WAKEUP_ACTIVE;
+   if (wake_up_process(wait->tsk))
+   result |= ENGINE_WAKEUP_ASLEEP;
}
-   spin_unlock_irqrestore(>breadcrumbs.lock, flags);
+
+   return result;
+}
+
+unsigned int intel_engine_wakeup(struct intel_engine_cs *engine)
+{
+   struct intel_breadcrumbs *b = >breadcrumbs;
+   unsigned long flags;
+   unsigned int result;
+
+   spin_lock_irqsave(>lock, flags);
+   result = __intel_breadcrumbs_wakeup(b);
+   spin_unlock_irqrestore(>lock, flags);
 
return result;
 }
@@ -54,7 +64,7 @@ static void intel_breadcrumbs_hangcheck(unsigned long data)
struct intel_engine_cs *engine = (struct intel_engine_cs *)data;
struct intel_breadcrumbs *b = >breadcrumbs;
 
-   if (!b->irq_enabled)
+   if (!b->irq_armed)
return;
 
if (b->hangcheck_interrupts != atomic_read(>irq_count)) {
@@ -63,23 +73,32 @@ static void intel_breadcrumbs_hangcheck(unsigned long data)
return;
}
 
-   /* If the waiter was currently running, assume it hasn't had a chance
+   /* We keep the hangcheck time alive until we disarm the irq, even
+* if there are no waiters at present.
+*
+* If the waiter was currently running, assume it hasn't had a chance
 * to process the pending interrupt (e.g, low priority task on a loaded
 * system) and wait until it sleeps before 

[Intel-gfx] [CI 1/4] drm/i915: Report both waiters and success from intel_engine_wakeup()

[Chris Wilson]

The two users of the return value from intel_engine_wakeup() are
expecting different results. In the breadcrumbs hangcheck, we are using
it to determine whether wake_up_process() detected the waiter was
currently running (and if so we presume that it hasn't yet missed the
interrupt). However, in the fake_irq path, we are using the return value
as a check as to whether there are any waiters, and so we may
incorrectly stop the fake-irq if that waiter was currently running.

To handle the two different needs, return both bits of information! We
uninline it from the irq path in preparation for the next patch which
makes the irq hotpath special and relegates intel_engine_wakeup() to the
slow fixup paths.

v2: s/ret/result/

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_breadcrumbs.c | 28 +++-
 drivers/gpu/drm/i915/intel_ringbuffer.h  | 26 +++---
 2 files changed, 30 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index 027c93e34c97..c8361f350350 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -26,6 +26,32 @@
 
 #include "i915_drv.h"
 
+unsigned int intel_engine_wakeup(struct intel_engine_cs *engine)
+{
+   unsigned int result = 0;
+
+   /* Note that for this not to dangerously chase a dangling pointer,
+* we must hold the rcu_read_lock here.
+*
+* Also note that tsk is likely to be in !TASK_RUNNING state so an
+* early test for tsk->state != TASK_RUNNING before wake_up_process()
+* is unlikely to be beneficial.
+*/
+   if (intel_engine_has_waiter(engine)) {
+   struct task_struct *tsk;
+
+   result = ENGINE_WAKEUP_WAITER;
+
+   rcu_read_lock();
+   tsk = rcu_dereference(engine->breadcrumbs.irq_seqno_bh);
+   if (tsk && !wake_up_process(tsk))
+   result |= ENGINE_WAKEUP_ACTIVE;
+   rcu_read_unlock();
+   }
+
+   return result;
+}
+
 static unsigned long wait_timeout(void)
 {
return round_jiffies_up(jiffies + DRM_I915_HANGCHECK_JIFFIES);
@@ -49,7 +75,7 @@ static void intel_breadcrumbs_hangcheck(unsigned long data)
 * to process the pending interrupt (e.g, low priority task on a loaded
 * system) and wait until it sleeps before declaring a missed interrupt.
 */
-   if (!intel_engine_wakeup(engine)) {
+   if (intel_engine_wakeup(engine) & ENGINE_WAKEUP_ACTIVE) {
mod_timer(>hangcheck, wait_timeout());
return;
}
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 0f29e07a9581..7d753dc1b89d 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -642,29 +642,9 @@ static inline bool intel_engine_has_waiter(const struct 
intel_engine_cs *engine)
return rcu_access_pointer(engine->breadcrumbs.irq_seqno_bh);
 }
 
-static inline bool intel_engine_wakeup(const struct intel_engine_cs *engine)
-{
-   bool wakeup = false;
-
-   /* Note that for this not to dangerously chase a dangling pointer,
-* we must hold the rcu_read_lock here.
-*
-* Also note that tsk is likely to be in !TASK_RUNNING state so an
-* early test for tsk->state != TASK_RUNNING before wake_up_process()
-* is unlikely to be beneficial.
-*/
-   if (intel_engine_has_waiter(engine)) {
-   struct task_struct *tsk;
-
-   rcu_read_lock();
-   tsk = rcu_dereference(engine->breadcrumbs.irq_seqno_bh);
-   if (tsk)
-   wakeup = wake_up_process(tsk);
-   rcu_read_unlock();
-   }
-
-   return wakeup;
-}
+unsigned int intel_engine_wakeup(struct intel_engine_cs *engine);
+#define ENGINE_WAKEUP_WAITER BIT(0)
+#define ENGINE_WAKEUP_ACTIVE BIT(1)
 
 void intel_engine_reset_breadcrumbs(struct intel_engine_cs *engine);
 void intel_engine_fini_breadcrumbs(struct intel_engine_cs *engine);
-- 
2.11.0

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

[Intel-gfx] [CI 3/4] drm/i915: Defer enabling hangcheck to the first fake breadcrumb interrupt

[Chris Wilson]

By deferring hangcheck to the fake breadcrumb interrupt, we can simply
the enabling procedure slightly - as by enabling the fake, we then
enable the hangcheck. By always enabling the hangcheck from each fake
interrupt (it will be a no-op for an already queued hangcheck), it will
make restoring the breadcrumbs after a reset simpler in the next patch.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_breadcrumbs.c | 36 
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index e7f4a4c923a2..3855c8c39b35 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -75,17 +75,6 @@ static void intel_breadcrumbs_hangcheck(unsigned long data)
DRM_DEBUG("Hangcheck timer elapsed... %s idle\n", engine->name);
set_bit(engine->id, >i915->gpu_error.missed_irq_rings);
mod_timer(>breadcrumbs.fake_irq, jiffies + 1);
-
-   /* Ensure that even if the GPU hangs, we get woken up.
-*
-* However, note that if no one is waiting, we never notice
-* a gpu hang. Eventually, we will have to wait for a resource
-* held by the GPU and so trigger a hangcheck. In the most
-* pathological case, this will be upon memory starvation! To
-* prevent this, we also queue the hangcheck from the retire
-* worker.
-*/
-   i915_queue_hangcheck(engine->i915);
 }
 
 static void intel_breadcrumbs_fake_irq(unsigned long data)
@@ -99,8 +88,21 @@ static void intel_breadcrumbs_fake_irq(unsigned long data)
 * every jiffie in order to kick the oldest waiter to do the
 * coherent seqno check.
 */
-   if (intel_engine_wakeup(engine))
-   mod_timer(>breadcrumbs.fake_irq, jiffies + 1);
+   if (!intel_engine_wakeup(engine))
+   return;
+
+   mod_timer(>breadcrumbs.fake_irq, jiffies + 1);
+
+   /* Ensure that even if the GPU hangs, we get woken up.
+*
+* However, note that if no one is waiting, we never notice
+* a gpu hang. Eventually, we will have to wait for a resource
+* held by the GPU and so trigger a hangcheck. In the most
+* pathological case, this will be upon memory starvation! To
+* prevent this, we also queue the hangcheck from the retire
+* worker.
+*/
+   i915_queue_hangcheck(engine->i915);
 }
 
 static void irq_enable(struct intel_engine_cs *engine)
@@ -179,13 +181,11 @@ static void __intel_breadcrumbs_enable_irq(struct 
intel_breadcrumbs *b)
b->irq_enabled = true;
}
 
-   if (!b->irq_enabled || use_fake_irq(b)) {
+   /* Ensure we never sleep indefinitely */
+   if (!b->irq_enabled || use_fake_irq(b))
mod_timer(>fake_irq, jiffies + 1);
-   i915_queue_hangcheck(i915);
-   } else {
-   /* Ensure we never sleep indefinitely */
+   else
mod_timer(>hangcheck, wait_timeout());
-   }
 }
 
 static void __intel_breadcrumbs_disable_irq(struct intel_breadcrumbs *b)
-- 
2.11.0

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

Re: [Intel-gfx] [PATCH] drm/i915: Only enable DDI IO power domains after enabling DPLL

[Ville Syrjälä]

On Fri, Feb 24, 2017 at 04:19:59PM +0200, Ander Conselvan de Oliveira wrote:
> According to bspec, the DDI IO power domains should be enabled after
> enabling the DPLL and mapping it to the DDI. The current order doesn't
> seem to create problems with Skylake and Kabylake, but causes enable
> timeouts in Geminilake.

This one seems to kill SKL+MST.

Just load the driver with an MST display plugged in and we get:
[   79.389527] Kernel panic - not syncing: Timeout: Not all CPUs entered 
broadcast exception handler

So presumably we're trying to access something that's not powered/clocked
and the CPU just gets totally stuck.

> 
> v2: Rebase.
>   - Take power domain references before sanitizing encoders. (Imre)
>   - Add comment to get_encoder_power_domains() defition. (Ander)
> 
> v3: Don't put the domain if called with HSW/BDW's analog encoder. (CI)
> 
> v4: Put IO power domain before unmapping DPLL. (Imre)
>   - Change return type of intel_ddi_get_power_domains() to u64. (Imre)
> 
> Cc: David Weinehall 
> Cc: Imre Deak 
> Signed-off-by: Ander Conselvan de Oliveira 
> 
> Reviewed-by: David Weinehall  # v1
> Reviewed-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/i915_drv.h |  5 +++
>  drivers/gpu/drm/i915/intel_ddi.c| 49 
>  drivers/gpu/drm/i915/intel_display.c| 20 ++
>  drivers/gpu/drm/i915/intel_drv.h|  4 ++
>  drivers/gpu/drm/i915/intel_runtime_pm.c | 68 
> +++--
>  5 files changed, 117 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 4673912..5a032ba 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -344,6 +344,11 @@ enum intel_display_power_domain {
>   POWER_DOMAIN_PORT_DDI_C_LANES,
>   POWER_DOMAIN_PORT_DDI_D_LANES,
>   POWER_DOMAIN_PORT_DDI_E_LANES,
> + POWER_DOMAIN_PORT_DDI_A_IO,
> + POWER_DOMAIN_PORT_DDI_B_IO,
> + POWER_DOMAIN_PORT_DDI_C_IO,
> + POWER_DOMAIN_PORT_DDI_D_IO,
> + POWER_DOMAIN_PORT_DDI_E_IO,
>   POWER_DOMAIN_PORT_DSI,
>   POWER_DOMAIN_PORT_CRT,
>   POWER_DOMAIN_PORT_OTHER,
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index b0c4d23..e9013f1 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1440,6 +1440,17 @@ bool intel_ddi_get_hw_state(struct intel_encoder 
> *encoder,
>   return ret;
>  }
>  
> +static u64 intel_ddi_get_power_domains(struct intel_encoder *encoder)
> +{
> + struct intel_digital_port *dig_port = enc_to_dig_port(>base);
> + enum pipe pipe;
> +
> + if (intel_ddi_get_hw_state(encoder, ))
> + return BIT_ULL(dig_port->ddi_io_power_domain);
> +
> + return 0;
> +}
> +
>  void intel_ddi_enable_pipe_clock(struct intel_crtc *intel_crtc)
>  {
>   struct drm_crtc *crtc = _crtc->base;
> @@ -1682,6 +1693,7 @@ static void intel_ddi_pre_enable_dp(struct 
> intel_encoder *encoder,
>   struct intel_dp *intel_dp = enc_to_intel_dp(>base);
>   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>   enum port port = intel_ddi_get_encoder_port(encoder);
> + struct intel_digital_port *dig_port = enc_to_dig_port(>base);
>  
>   intel_dp_set_link_params(intel_dp, link_rate, lane_count,
>link_mst);
> @@ -1689,6 +1701,9 @@ static void intel_ddi_pre_enable_dp(struct 
> intel_encoder *encoder,
>   intel_edp_panel_on(intel_dp);
>  
>   intel_ddi_clk_select(encoder, pll);
> +
> + intel_display_power_get(dev_priv, dig_port->ddi_io_power_domain);
> +
>   intel_prepare_dp_ddi_buffers(encoder);
>   intel_ddi_init_dp_buf_reg(encoder);
>   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> @@ -1708,9 +1723,13 @@ static void intel_ddi_pre_enable_hdmi(struct 
> intel_encoder *encoder,
>   struct drm_encoder *drm_encoder = >base;
>   enum port port = intel_ddi_get_encoder_port(encoder);
>   int level = intel_ddi_hdmi_level(dev_priv, port);
> + struct intel_digital_port *dig_port = enc_to_dig_port(>base);
>  
>   intel_dp_dual_mode_set_tmds_output(intel_hdmi, true);
>   intel_ddi_clk_select(encoder, pll);
> +
> + intel_display_power_get(dev_priv, dig_port->ddi_io_power_domain);
> +
>   intel_prepare_hdmi_ddi_buffers(encoder);
>   if (IS_GEN9_BC(dev_priv))
>   skl_ddi_set_iboost(encoder, level);
> @@ -1754,6 +1773,7 @@ static void intel_ddi_post_disable(struct intel_encoder 
> *intel_encoder,
>   struct drm_encoder *encoder = _encoder->base;
>   struct drm_i915_private *dev_priv = to_i915(encoder->dev);
>   enum port port = intel_ddi_get_encoder_port(intel_encoder);
> + struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
>   int 

Re: [Intel-gfx] [PATCH v5 4/4] drm/i915: Delay disabling the user interrupt for breadcrumbs

[Tvrtko Ursulin]

On 27/02/2017 14:13, Chris Wilson wrote:

On Mon, Feb 27, 2017 at 02:06:58PM +, Chris Wilson wrote:

On Mon, Feb 27, 2017 at 01:57:35PM +, Tvrtko Ursulin wrote:


On 27/02/2017 13:24, Chris Wilson wrote:

if (b->hangcheck_interrupts != atomic_read(>irq_count)) {
@@ -67,7 +76,7 @@ static void intel_breadcrumbs_hangcheck(unsigned long data)
 * to process the pending interrupt (e.g, low priority task on a loaded
 * system) and wait until it sleeps before declaring a missed interrupt.
 */
-   if (intel_engine_wakeup(engine) & ENGINE_WAKEUP_ACTIVE) {
+   if (!(intel_engine_wakeup(engine) & ENGINE_WAKEUP_ASLEEP)) {


I did not get the explanation from the previous round on why you had
to reverse the active to asleep. Here it even looks wrong now,
because I thought you don't want to re-queue the hangcheck when
there are no waiters?


No waiters: result = 0
Running waiter: result = WAKEUP_WAITER
Sleeping waiter: result = WAKEUP_WAITER | WAKEUP_ASLEEP

We only want to declare a mised irq if we wake up a sleeping waiter, and
keep the hangcheck timer running until the device is idle (when the irq
is disarmed).

How about:

if (intel_engine_wakeup(engine) & ENGINE_WAKEUP_ASLEEP) {
set_bit(missed_irq);
mod_timer(>fake_irq, jiffies + 1);
} else {
mod_timer(b->hangcheck, wait_timeout);
}


diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index ebb7bc0be9fb..004eb4c0c531 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -72,18 +72,25 @@ static void intel_breadcrumbs_hangcheck(unsigned long data)
return;
}

-   /* If the waiter was currently running, assume it hasn't had a chance
+   /* We keep the hangcheck time alive until we disarm the irq, even
+* if there are no waiters at present.
+*
+* If the waiter was currently running, assume it hasn't had a chance
 * to process the pending interrupt (e.g, low priority task on a loaded
 * system) and wait until it sleeps before declaring a missed interrupt.
+*
+* If the waiter was asleep (and not even pending a wakeup), then we
+* must have missed an interrupt as the GPU has stopped advancing
+* but we still have a waiter. Assuming all batches complete within
+* DRM_I915_HANGCHECK_JIFFIES [1.5s]!
 */
-   if (!(intel_engine_wakeup(engine) & ENGINE_WAKEUP_ASLEEP)) {
+   if (intel_engine_wakeup(engine) & ENGINE_WAKEUP_ASLEEP) {
+   DRM_DEBUG("Hangcheck timer elapsed... %s idle\n", engine->name);
+   set_bit(engine->id, >i915->gpu_error.missed_irq_rings);
+   mod_timer(>breadcrumbs.fake_irq, jiffies + 1);
+   } else {
mod_timer(>hangcheck, wait_timeout());
-   return;
}
-
-   DRM_DEBUG("Hangcheck timer elapsed... %s idle\n", engine->name);
-   set_bit(engine->id, >i915->gpu_error.missed_irq_rings);
-   mod_timer(>breadcrumbs.fake_irq, jiffies + 1);
 }

 static void intel_breadcrumbs_fake_irq(unsigned long data)
@@ -167,6 +174,10 @@ void intel_engine_disarm_breadcrumbs(struct 
intel_engine_cs *engine)

spin_lock_irqsave(>lock, flags);

+   /* We only disarm the irq when we are idle (all requests completed),
+* so if there remains a sleeping waiter, it missed the request
+* completion.
+*/
if (__intel_engine_wakeup(engine) & ENGINE_WAKEUP_ASLEEP)
set_bit(engine->id, >i915->gpu_error.missed_irq_rings);





Looks okay after some re-re-re-reading. I guess shuffling things back 
and forth in this series, not long after the area was recently changed 
as well, was a bit challenging.


Reviewed-by: Tvrtko Ursulin 

Regards,

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

Re: [Intel-gfx] [PATCH v3 4/8] drm: Add driver-private objects to atomic state

[Pandiyan, Dhinakaran]

On Sun, 2017-02-26 at 20:57 +0100, Daniel Vetter wrote:
> On Wed, Feb 22, 2017 at 12:01:12AM +, Pandiyan, Dhinakaran wrote:
> > On Fri, 2017-02-17 at 15:37 +0530, Archit Taneja wrote:
> > > 
> > > On 02/16/2017 05:43 AM, Pandiyan, Dhinakaran wrote:
> > > > On Wed, 2017-02-15 at 16:53 +0530, Archit Taneja wrote:
> > > >> Comparing this func to 
> > > >> drm_atomic_get_plane_state/drm_atomic_get_crtc_state, it
> > > >> doesn't seem to call drm_modeset_lock if the obj_state doesn't already 
> > > >> exist. I
> > > >> don't understand the locking stuff toowell, I just noticed this 
> > > >> difference when
> > > >> comparing this approach with what is done in the msm kms driver (where 
> > > >> we
> > > >> have subclassed drm_atomic_state to msm_kms_state).
> > > >>
> > > >> Thanks,
> > > >> Archit
> > > >>
> > > >
> > > >
> > > > The caller is expected to take care of any required locking. The
> > > > driver-private objects are opaque from core's pov, so the core is not
> > > > aware of necessary locks for that object type.
> > > 
> > > I had a look at the rest of the series, and I couldn't easily understand
> > > whether the caller code protects the MST related driver private state. Is
> > > it expected to be protect via the drm_mode_config.connection_mutex lock?
> > > 
> > > Thanks,
> > > Archit
> > > 
> > 
> > That's right, the connection_mutex takes care of the locking for the MST
> > private state. I can add that as a comment to the caller's (MST helper)
> > kernel doc with a
> > 
> > WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex)); 
> 
> Please don't add this as a comment, but as real code so it is checked at
> runtime :-) Personally I wouldn't mention locking rules in kernel-doc,
> that part tends to get outdated fast. Better to enforce with
> runtime-checks.
> -Daniel

That's what I meant but evidently didn't type it that way:) I was going
to add that the connection_mutex does the locking for MST state as a
comment and put the WARN_ON() in code.

-DK

___
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/edid: Add EDID_QUIRK_FORCE_8BPC quirk for Rotel RSX-1058

[Patchwork]

== Series Details ==

Series: drm/edid: Add EDID_QUIRK_FORCE_8BPC quirk for Rotel RSX-1058
URL   : https://patchwork.freedesktop.org/series/19959/
State : success

== Summary ==

Series 19959v1 drm/edid: Add EDID_QUIRK_FORCE_8BPC quirk for Rotel RSX-1058
https://patchwork.freedesktop.org/api/1.0/series/19959/revisions/1/mbox/

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-skl-6700k)

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:108  pass:95   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29 

ea59cd057f94642a3e16f1059fc518faae14e0a8 drm-tip: 2017y-02m-27d-17h-23m-21s UTC 
integration manifest
841b1a1 drm/edid: Add EDID_QUIRK_FORCE_8BPC quirk for Rotel RSX-1058

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915/dsi: VLV/CHT Only wait for LP00 on MIPI PORT A

[Bob Paauwe]

On Mon, 27 Feb 2017 11:22:32 +0100
Hans de Goede  wrote:

> On some devices only MIPI PORT C is used, in this case checking the
> MIPI PORT A CTRL AFE_LATCHOUT bit (there is no such bit for PORT C
> on VLV/CHT) will result in false positive "DSI LP not going Low" errors
> as this checks the PORT A clk status.
> 
> In case both ports are used we have already checked the AFE_LATCHOUT
> bit when going through the for_each_dsi_port() loop for PORT A and
> checking the same bit again for PORT C is a no-op.
> 
> BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=97061
> Signed-off-by: Hans de Goede 

Reviewed-by: Bob Paauwe 

> ---
>  drivers/gpu/drm/i915/intel_dsi.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
> b/drivers/gpu/drm/i915/intel_dsi.c
> index 1fcce2c..185b8eb 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -458,10 +458,12 @@ static void intel_dsi_clear_device_ready(struct 
> intel_encoder *encoder)
>   ULPS_STATE_ENTER);
>   usleep_range(2000, 2500);
>  
> - /* Wait till Clock lanes are in LP-00 state for MIPI Port A
> -  * only. MIPI Port C has no similar bit for checking
> + /*
> +  * On VLV/CHV, wait till Clock lanes are in LP-00 state for MIPI
> +  * Port A only. MIPI Port C has no similar bit for checking.
>*/
> - if (intel_wait_for_register(dev_priv,
> + if ((IS_GEN9_LP(dev_priv) || port == PORT_A) &&
> + intel_wait_for_register(dev_priv,
>   port_ctrl, AFE_LATCHOUT, 0,
>   30))
>   DRM_ERROR("DSI LP not going Low\n");



-- 
--
Bob Paauwe  
bob.j.paa...@intel.com
IOTG / PED Software Organization
Intel Corp.  Folsom, CA
(916) 356-6193

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

Re: [Intel-gfx] [PATCH resend 13/15] drm/i915/dsi: Execute MIPI_SEQ_TEAR_OFF from intel_dsi_post_disable

[Jani Nikula]

On Sat, 25 Feb 2017, Hans de Goede  wrote:
> Hi,
>
> On 24-02-17 18:02, Bob Paauwe wrote:
>> On Mon, 20 Feb 2017 15:08:43 +0100
>> Hans de Goede  wrote:
>>
>>> For v3 VBTs we should call MIPI_SEQ_TEAR_OFF before
>>> MIPI_SEQ_DISPLAY_OFF, for non v3 VBTs this is a nop.
>>
>> Isn't this only for command mode?  Or is there conflicting information
>> on this?
>
> In my (limited) set of test hardware vidmode panel VBTs simply
> do not define a MIPI_SEQ_TEAR_ON/OFF sequence. But it would probably
> be a good idea to guard this with a "if (is_cmd_mode(intel_dsi))"
> assuming we only want this for commandmode, which I think we do,
> but it would be good to have this confirmed.

Logically you wouldn't do tear on/off on video mode panels. But that's
really not the point. I wouldn't be surprised if there were setups where
someone noticed that this particular sequence gets run at an appropriate
time on Windows, and shoved some other stuff there, completely unrelated
to tear on/off.

BR,
Jani.


>
> I'll add the guard when I send out a v2 after we've clarified
> some of the other review questions.
>
> Regards,
>
> Hans
>
>
>
>>
>>>
>>> Signed-off-by: Hans de Goede 
>>> ---
>>>  drivers/gpu/drm/i915/intel_dsi.c | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
>>> b/drivers/gpu/drm/i915/intel_dsi.c
>>> index 1914311..90263d6 100644
>>> --- a/drivers/gpu/drm/i915/intel_dsi.c
>>> +++ b/drivers/gpu/drm/i915/intel_dsi.c
>>> @@ -772,6 +772,7 @@ static void intel_dsi_post_disable(struct intel_encoder 
>>> *encoder,
>>>  * XXX spec specifies SHUTDOWN before MIPI_SEQ_DISPLAY_OFF for
>>>  * v3 VBTs, but not for v2 VBTs?
>>>  */
>>> +   intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_TEAR_OFF);
>>> intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_OFF);
>>>
>>> /* Transition to LP-00 */
>>
>>
>>

-- 
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 resend 12/15] drm/i915/dsi: Document always using v3 SHUTDOWN / MIPI_SEQ_DISPLAY_OFF order

[Jani Nikula]

On Mon, 27 Feb 2017, Bob Paauwe  wrote:
> On Sat, 25 Feb 2017 11:42:09 +0100
> Hans de Goede  wrote:
>
>> Hi,
>> 
>> On 24-02-17 18:02, Bob Paauwe wrote:
>> > On Mon, 20 Feb 2017 15:08:42 +0100
>> > Hans de Goede  wrote:
>> >  
>> >> According to the spec for v2 VBTs we should call MIPI_SEQ_DISPLAY_OFF
>> >> before sending SHUTDOWN, where as for v3 VBTs we should send SHUTDOWN
>> >> first.
>> >>
>> >> Since the v2 order has known issues, we use the v3 order everywhere,
>> >> add a comment documenting this.
>> >>
>> >> Signed-off-by: Hans de Goede 
>> >> ---
>> >>  drivers/gpu/drm/i915/intel_dsi.c | 7 +++
>> >>  1 file changed, 7 insertions(+)
>> >>
>> >> diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
>> >> b/drivers/gpu/drm/i915/intel_dsi.c
>> >> index a8d0948..1914311 100644
>> >> --- a/drivers/gpu/drm/i915/intel_dsi.c
>> >> +++ b/drivers/gpu/drm/i915/intel_dsi.c
>> >> @@ -732,6 +732,11 @@ static void intel_dsi_pre_disable(struct 
>> >> intel_encoder *encoder,
>> >>   I915_WRITE(MIPI_DEVICE_READY(port), 0);
>> >>   }
>> >>
>> >> + /*
>> >> +  * XXX: According to the spec we should send SHUTDOWN before
>> >> +  * MIPI_SEQ_DISPLAY_OFF only for v3+ VBTs, but testing in the field
>> >> +  * has shown that we should do this for v2 VBTs too?  
>> > drop the '?'  
>> 
>> I added that because I'm not 100% sure this is true, looking through git
>> history (and android x86 kernel patch-sets) I managed to piece together that
>> at one point in time the v2 sequence was used, but that yielded problems
>> during some testing, what the commits do not tell if is that testing was
>> using boards with v3 VBTs, but assuming v2 tables are out there in the
>> wild then it seems that the v3 order works fine for v2 too.
>> 
>> TLDR I'm not 100% sure about this hence the '?', my main goal with this
>> patch is to document that we're deviating from the spec for v2 tables here.
>
> If anyone else, Jani?, has more information about this, that would be
> good to know.  

I wish. The documentation on this is disgraceful.

> I'd be OK with just stating that "field testing has shown that the v3
> sequence works with v2 VBT's so just use that."

Ack.

>
>> 
>> >> +  */
>> >>   if (is_vid_mode(intel_dsi)) {
>> >>   /* Send Shutdown command to the panel in LP mode */
>> >>   for_each_dsi_port(port, intel_dsi->ports)
>> >> @@ -764,6 +769,8 @@ static void intel_dsi_post_disable(struct 
>> >> intel_encoder *encoder,
>> >>   /*
>> >>* if disable packets are sent before sending shutdown packet then in
>> >>* some next enable sequence send turn on packet error is observed
>> >> +  * XXX spec specifies SHUTDOWN before MIPI_SEQ_DISPLAY_OFF for
>> >> +  * v3 VBTs, but not for v2 VBTs?
>> >>*/
>> >>   intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_OFF);
>> >>  
>> >
>> > Should XXX be replaced with something?  
>> 
>> XXX is used in many places in intel_dsi.c to indicate code which may need
>> work / which may needs to be investigated further. I followed that and
>> added XXX here since this code is deviating from the spec.
>> 
>> Regards,
>> 
>> Hans

-- 
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 resend 11/15] drm/i915/dsi: Group MIPI_SEQ_BACKLIGHT_ON/OFF with panel_[en|dis]able_backlight

[Jani Nikula]

On Mon, 27 Feb 2017, Bob Paauwe  wrote:
> On Sat, 25 Feb 2017 11:37:50 +0100
> Hans de Goede  wrote:
>
>> Hi,
>> 
>> On 24-02-17 18:00, Bob Paauwe wrote:
>> > On Mon, 20 Feb 2017 15:08:41 +0100
>> > Hans de Goede  wrote:
>> >  
>> >> Execute the MIPI_SEQ_BACKLIGHT_ON/OFF VBT sequences at the same time as
>> >> we call intel_panel_enable_backlight() / intel_panel_disable_backlight().
>> >>
>> >> Signed-off-by: Hans de Goede   
>> >
>> > I'm not sure that the added comments are necessary.  Maybe if there was
>> > some explanation for why we're using two different mechanisms to
>> > enable/disable backlight instead.  
>> 
>> That assumes I know why there are 2 mechanisms of I have to guess it
>> is because on some boards only one of the mechanisms works, but that
>> is just a guess. Just calling the VBT sequence should be enough on
>> (most?) boards.
>> 
>> Regards,
>> 
>> Hans
>
> I don't think I can describe why we have two mechanisms so just
> dropping the comment would be my preference at this point.

I think they're mostly alternatives, and only one or the other gets
used, but since the VBT sequence is rather generic, I think it's
possible one controls the SoC side and the other the panel side.

> It may be that calling the intel_panel_enable_backlight() will make
> sure the sysfs entries are correct while the VBT sequence simply
> modifies the hardware. 
>
> Possibly a good solution would be to enhance the code that executes the
> VBT sequence to also call the intel_panel_enable_backlight(), but
> that's not something to change here.

Please leave it as it is.

BR,
Jani.

>
>> 
>> 
>> >
>> > Reviewed-by: Bob Paauwe 
>> >  
>> >> ---
>> >>  drivers/gpu/drm/i915/intel_dsi.c | 6 --
>> >>  1 file changed, 4 insertions(+), 2 deletions(-)
>> >>
>> >> diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
>> >> b/drivers/gpu/drm/i915/intel_dsi.c
>> >> index 8408f59..a8d0948 100644
>> >> --- a/drivers/gpu/drm/i915/intel_dsi.c
>> >> +++ b/drivers/gpu/drm/i915/intel_dsi.c
>> >> @@ -687,12 +687,13 @@ static void intel_dsi_pre_enable(struct 
>> >> intel_encoder *encoder,
>> >>   msleep(100);
>> >>
>> >>   intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_ON);
>> >> - intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_ON);
>> >>
>> >>   intel_dsi_port_enable(encoder);
>> >>   }
>> >>
>> >> + /* Enable backlight, both pwm and VBT */
>> >>   intel_panel_enable_backlight() (intel_dsi->attached_connector);
>> >> + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_ON);
>> >>  }
>> >>
>> >>  static void intel_dsi_enable_nop(struct intel_encoder *encoder,
>> >> @@ -718,6 +719,8 @@ static void intel_dsi_pre_disable(struct 
>> >> intel_encoder *encoder,
>> >>
>> >>   DRM_DEBUG_KMS("\n");
>> >>
>> >> + /* Disable backlight, both VBT and pwm */
>> >> + intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_OFF);
>> >>   intel_panel_disable_backlight(intel_dsi->attached_connector);
>> >>
>> >>   /*
>> >> @@ -762,7 +765,6 @@ static void intel_dsi_post_disable(struct 
>> >> intel_encoder *encoder,
>> >>* if disable packets are sent before sending shutdown packet then in
>> >>* some next enable sequence send turn on packet error is observed
>> >>*/
>> >> - intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_OFF);
>> >>   intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_OFF);
>> >>
>> >>   /* Transition to LP-00 */  
>> >
>> >
>> >  

-- 
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 resend 14/15] drm/i915/dsi: Call MIPI_SEQ_TEAR_ON and DISPLAY_ON for cmd-mode (untested)

[Bob Paauwe]

On Sat, 25 Feb 2017 11:47:32 +0100
Hans de Goede  wrote:

> Hi,
> 
> On 24-02-17 18:02, Bob Paauwe wrote:
> > On Mon, 20 Feb 2017 15:08:44 +0100
> > Hans de Goede  wrote:
> >  
> >> According to the spec we should call MIPI_SEQ_TEAR_ON and DISPLAY_ON
> >> on enable for cmd-mode, just like we already call their counterparts
> >> on disable. Note: untested, my panel is a vid-mode panel.
> >>
> >> Signed-off-by: Hans de Goede 
> >> ---
> >>  drivers/gpu/drm/i915/intel_dsi.c | 2 ++
> >>  1 file changed, 2 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
> >> b/drivers/gpu/drm/i915/intel_dsi.c
> >> index 90263d6..a001e43 100644
> >> --- a/drivers/gpu/drm/i915/intel_dsi.c
> >> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> >> @@ -680,6 +680,8 @@ static void intel_dsi_pre_enable(struct intel_encoder 
> >> *encoder,
> >>if (is_cmd_mode(intel_dsi)) {
> >>for_each_dsi_port(port, intel_dsi->ports)
> >>I915_WRITE(MIPI_MAX_RETURN_PKT_SIZE(port), 8 * 4);
> >> +  intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_TEAR_ON);  
> >
> > As with the TEAR_OFF, should this only be done for command mode?  Or is
> > it just a no-op for video mode and doesn't matter?  
> 
> In this case we are actually in a "if (is_cmd_mode(intel_dsi)) {" code
> block (the if is visible in the diff context).
> 
> Which I guess also shows that we really need to add the guard to the
> other path, so as to be consistent.
> 
> Note as mentioned in the commit msg:
> 
> untested, my panel is a vid-mode panel.

Oops, sorry.  I think there's another block of code somewhere that
looks almost like this but was wrapped in an if (is_vid_mode) condition
and I confused the two.

So disregard my comment and add:

Reviewed-by: Bob Paauwe 

> 
> >  
> >> +  intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_ON);
> >>} else {
> >>msleep(20); /* XXX */
> >>for_each_dsi_port(port, intel_dsi->ports)  
> >
> >
> >  
> 
> Regards,
> 
> Hans



-- 
--
Bob Paauwe  
bob.j.paa...@intel.com
IOTG / PED Software Organization
Intel Corp.  Folsom, CA
(916) 356-6193

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

Re: [Intel-gfx] [PATCH] drm/i915: Distinguish between timeout and error in sideband transactions

[Chris Wilson]

On Mon, Feb 27, 2017 at 06:34:26PM +0200, Jani Nikula wrote:
> On Thu, 23 Feb 2017, Chris Wilson  wrote:
> > After initiating a sideband transaction, we only want to wait for the
> > transaction to become idle. If, as we are, we wait for both the busy
> > and error flag to clear, if an error is raised we just spin until the
> > timeout. Once the hw is idle, we can then check to see if the hw flagged
> > an error, and report it distinctly.
> >
> > Signed-off-by: Chris Wilson 
> > Cc: Jani Nikula 
> 
> Much better indeed.
> 
> Reviewed-by: Jani Nikula 
> 
> (The pedantic nitpick is that response status is really two bits, and
> you could read them both and fail if they're not zero. But meh.)

First goal is just figuring out what the warnings mean on the gvtg
machines. :)
-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 resend 15/15] drm/i915/dsi: Skip delays for v3 VBTs in vid-mode

[Bob Paauwe]

On Sat, 25 Feb 2017 11:49:09 +0100
Hans de Goede  wrote:

> HI,
> 
> On 24-02-17 18:02, Bob Paauwe wrote:
> > On Mon, 20 Feb 2017 15:08:45 +0100
> > Hans de Goede  wrote:
> >  
> >> For v3 VBTs in vid-mode the delays are part of the VBT sequences, so
> >> we should not also delay ourselves otherwise we get double delays.
> >>
> >> Signed-off-by: Hans de Goede 
> >> ---
> >>  drivers/gpu/drm/i915/intel_dsi.c | 19 +++
> >>  1 file changed, 15 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
> >> b/drivers/gpu/drm/i915/intel_dsi.c
> >> index a001e43..9e858c7 100644
> >> --- a/drivers/gpu/drm/i915/intel_dsi.c
> >> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> >> @@ -552,6 +552,17 @@ static void intel_dsi_prepare(struct intel_encoder 
> >> *intel_encoder,
> >>  struct intel_crtc_state *pipe_config);
> >>  static void intel_dsi_unprepare(struct intel_encoder *encoder);
> >>
> >> +static void intel_dsi_msleep(struct intel_dsi *intel_dsi, int msec)
> >> +{
> >> +  struct drm_i915_private *dev_priv = to_i915(intel_dsi->base.base.dev);
> >> +
> >> +  /* For v3 VBTs in vid-mode the delays are part of the VBT sequences */
> >> +  if (is_vid_mode(intel_dsi) && dev_priv->vbt.dsi.seq_version >= 3)
> >> +  return;
> >> +
> >> +  msleep(msec);
> >> +}
> >> +
> >>  /*
> >>   * Panel enable/disable sequences from the VBT spec.
> >>   *
> >> @@ -664,7 +675,7 @@ static void intel_dsi_pre_enable(struct intel_encoder 
> >> *encoder,
> >>if (intel_dsi->gpio_panel)
> >>gpiod_set_value_cansleep(intel_dsi->gpio_panel, 1);
> >>intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_POWER_ON);
> >> -  msleep(intel_dsi->panel_on_delay);
> >> +  intel_dsi_msleep(intel_dsi, intel_dsi->panel_on_delay);
> >>
> >>/* Deassert reset */
> >>intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DEASSERT_RESET);
> >> @@ -686,7 +697,7 @@ static void intel_dsi_pre_enable(struct intel_encoder 
> >> *encoder,
> >>msleep(20); /* XXX */
> >>for_each_dsi_port(port, intel_dsi->ports)
> >>dpi_send_cmd(intel_dsi, TURN_ON, false, port);
> >> -  msleep(100);
> >> +  intel_dsi_msleep(intel_dsi, 100);
> >>
> >>intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_ON);
> >>
> >> @@ -805,7 +816,7 @@ static void intel_dsi_post_disable(struct 
> >> intel_encoder *encoder,
> >>intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_ASSERT_RESET);
> >>
> >>/* Power off, try both CRC pmic gpio and VBT */
> >> -  msleep(intel_dsi->panel_off_delay);
> >> +  intel_dsi_msleep(intel_dsi, intel_dsi->panel_off_delay);
> >>intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_POWER_OFF);
> >>if (intel_dsi->gpio_panel)
> >>gpiod_set_value_cansleep(intel_dsi->gpio_panel, 0);
> >> @@ -814,7 +825,7 @@ static void intel_dsi_post_disable(struct 
> >> intel_encoder *encoder,
> >> * FIXME As we do with eDP, just make a note of the time here
> >> * and perform the wait before the next panel power on.
> >> */  
> >
> > Should this comment be updated now?  
> 
> It is still valid for non-vidmode and v2 VBT panels, so I think it can
> be left as is.
> 
> Regards,
> 
> Hans

OK, that makes sense.

> 
> 
> >
> > Otherwise
> > Reviewed-by: Bob Paauwe 
> >  
> >> -  msleep(intel_dsi->panel_pwr_cycle_delay);
> >> +  intel_dsi_msleep(intel_dsi, intel_dsi->panel_pwr_cycle_delay);
> >>  }
> >>
> >>  static bool intel_dsi_get_hw_state(struct intel_encoder *encoder,  
> >
> >
> >  



-- 
--
Bob Paauwe  
bob.j.paa...@intel.com
IOTG / PED Software Organization
Intel Corp.  Folsom, CA
(916) 356-6193

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Stop using RP_DOWN_EI on Baytrail

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: Stop using RP_DOWN_EI on Baytrail
URL   : https://patchwork.freedesktop.org/series/20314/
State : success

== Summary ==

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:108  pass:95   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29 

4113d7e37104478a568ef924afe9b45db11587e6 drm-tip: 2017y-02m-27d-16h-28m-48s UTC 
integration manifest
444e23e drm/i915: Defer unmasking RPS interrupts until after making adjustments
ecacd5c drm/i915: Stop using RP_DOWN_EI on Baytrail

== Logs ==

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

Re: [Intel-gfx] [PATCH resend 12/15] drm/i915/dsi: Document always using v3 SHUTDOWN / MIPI_SEQ_DISPLAY_OFF order

[Bob Paauwe]

On Sat, 25 Feb 2017 11:42:09 +0100
Hans de Goede  wrote:

> Hi,
> 
> On 24-02-17 18:02, Bob Paauwe wrote:
> > On Mon, 20 Feb 2017 15:08:42 +0100
> > Hans de Goede  wrote:
> >  
> >> According to the spec for v2 VBTs we should call MIPI_SEQ_DISPLAY_OFF
> >> before sending SHUTDOWN, where as for v3 VBTs we should send SHUTDOWN
> >> first.
> >>
> >> Since the v2 order has known issues, we use the v3 order everywhere,
> >> add a comment documenting this.
> >>
> >> Signed-off-by: Hans de Goede 
> >> ---
> >>  drivers/gpu/drm/i915/intel_dsi.c | 7 +++
> >>  1 file changed, 7 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
> >> b/drivers/gpu/drm/i915/intel_dsi.c
> >> index a8d0948..1914311 100644
> >> --- a/drivers/gpu/drm/i915/intel_dsi.c
> >> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> >> @@ -732,6 +732,11 @@ static void intel_dsi_pre_disable(struct 
> >> intel_encoder *encoder,
> >>I915_WRITE(MIPI_DEVICE_READY(port), 0);
> >>}
> >>
> >> +  /*
> >> +   * XXX: According to the spec we should send SHUTDOWN before
> >> +   * MIPI_SEQ_DISPLAY_OFF only for v3+ VBTs, but testing in the field
> >> +   * has shown that we should do this for v2 VBTs too?  
> > drop the '?'  
> 
> I added that because I'm not 100% sure this is true, looking through git
> history (and android x86 kernel patch-sets) I managed to piece together that
> at one point in time the v2 sequence was used, but that yielded problems
> during some testing, what the commits do not tell if is that testing was
> using boards with v3 VBTs, but assuming v2 tables are out there in the
> wild then it seems that the v3 order works fine for v2 too.
> 
> TLDR I'm not 100% sure about this hence the '?', my main goal with this
> patch is to document that we're deviating from the spec for v2 tables here.

If anyone else, Jani?, has more information about this, that would be
good to know.  

I'd be OK with just stating that "field testing has shown that the v3
sequence works with v2 VBT's so just use that."

> 
> >> +   */
> >>if (is_vid_mode(intel_dsi)) {
> >>/* Send Shutdown command to the panel in LP mode */
> >>for_each_dsi_port(port, intel_dsi->ports)
> >> @@ -764,6 +769,8 @@ static void intel_dsi_post_disable(struct 
> >> intel_encoder *encoder,
> >>/*
> >> * if disable packets are sent before sending shutdown packet then in
> >> * some next enable sequence send turn on packet error is observed
> >> +   * XXX spec specifies SHUTDOWN before MIPI_SEQ_DISPLAY_OFF for
> >> +   * v3 VBTs, but not for v2 VBTs?
> >> */
> >>intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_OFF);
> >>  
> >
> > Should XXX be replaced with something?  
> 
> XXX is used in many places in intel_dsi.c to indicate code which may need
> work / which may needs to be investigated further. I followed that and
> added XXX here since this code is deviating from the spec.
> 
> Regards,
> 
> Hans



-- 
--
Bob Paauwe  
bob.j.paa...@intel.com
IOTG / PED Software Organization
Intel Corp.  Folsom, CA
(916) 356-6193

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

Re: [Intel-gfx] [PATCH resend 11/15] drm/i915/dsi: Group MIPI_SEQ_BACKLIGHT_ON/OFF with panel_[en|dis]able_backlight

[Bob Paauwe]

On Sat, 25 Feb 2017 11:37:50 +0100
Hans de Goede  wrote:

> Hi,
> 
> On 24-02-17 18:00, Bob Paauwe wrote:
> > On Mon, 20 Feb 2017 15:08:41 +0100
> > Hans de Goede  wrote:
> >  
> >> Execute the MIPI_SEQ_BACKLIGHT_ON/OFF VBT sequences at the same time as
> >> we call intel_panel_enable_backlight() / intel_panel_disable_backlight().
> >>
> >> Signed-off-by: Hans de Goede   
> >
> > I'm not sure that the added comments are necessary.  Maybe if there was
> > some explanation for why we're using two different mechanisms to
> > enable/disable backlight instead.  
> 
> That assumes I know why there are 2 mechanisms of I have to guess it
> is because on some boards only one of the mechanisms works, but that
> is just a guess. Just calling the VBT sequence should be enough on
> (most?) boards.
> 
> Regards,
> 
> Hans

I don't think I can describe why we have two mechanisms so just
dropping the comment would be my preference at this point.

It may be that calling the intel_panel_enable_backlight() will make
sure the sysfs entries are correct while the VBT sequence simply
modifies the hardware. 

Possibly a good solution would be to enhance the code that executes the
VBT sequence to also call the intel_panel_enable_backlight(), but
that's not something to change here.

> 
> 
> >
> > Reviewed-by: Bob Paauwe 
> >  
> >> ---
> >>  drivers/gpu/drm/i915/intel_dsi.c | 6 --
> >>  1 file changed, 4 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
> >> b/drivers/gpu/drm/i915/intel_dsi.c
> >> index 8408f59..a8d0948 100644
> >> --- a/drivers/gpu/drm/i915/intel_dsi.c
> >> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> >> @@ -687,12 +687,13 @@ static void intel_dsi_pre_enable(struct 
> >> intel_encoder *encoder,
> >>msleep(100);
> >>
> >>intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_ON);
> >> -  intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_ON);
> >>
> >>intel_dsi_port_enable(encoder);
> >>}
> >>
> >> +  /* Enable backlight, both pwm and VBT */
> >>intel_panel_enable_backlight() (intel_dsi->attached_connector);
> >> +  intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_ON);
> >>  }
> >>
> >>  static void intel_dsi_enable_nop(struct intel_encoder *encoder,
> >> @@ -718,6 +719,8 @@ static void intel_dsi_pre_disable(struct intel_encoder 
> >> *encoder,
> >>
> >>DRM_DEBUG_KMS("\n");
> >>
> >> +  /* Disable backlight, both VBT and pwm */
> >> +  intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_OFF);
> >>intel_panel_disable_backlight(intel_dsi->attached_connector);
> >>
> >>/*
> >> @@ -762,7 +765,6 @@ static void intel_dsi_post_disable(struct 
> >> intel_encoder *encoder,
> >> * if disable packets are sent before sending shutdown packet then in
> >> * some next enable sequence send turn on packet error is observed
> >> */
> >> -  intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_OFF);
> >>intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DISPLAY_OFF);
> >>
> >>/* Transition to LP-00 */  
> >
> >
> >  



-- 
--
Bob Paauwe  
bob.j.paa...@intel.com
IOTG / PED Software Organization
Intel Corp.  Folsom, CA
(916) 356-6193

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

Re: [Intel-gfx] [PATCH resend 07/15] drm/i915/dsi: Drop bogus MIPI_SEQ_ASSERT_RESET before POWER_ON

[Bob Paauwe]

On Sat, 25 Feb 2017 11:35:03 +0100
Hans de Goede  wrote:

> Hi,
> 
> On 24-02-17 18:00, Bob Paauwe wrote:
> > On Mon, 20 Feb 2017 15:08:37 +0100
> > Hans de Goede  wrote:
> >  
> >> MIPI_SEQ_ASSERT_RESET before POWER_ON is not necessary for 2 reasons:
> >> 1) The reset should already be asserted before intel_dsi_pre_enable()
> >>gets called
> >> 2) Most (some?) VBTs will ensure reset was asserted in their
> >>MIPI_SEQ_DEASSERT_RESET themselves
> >>
> >> Signed-off-by: Hans de Goede   
> >
> > Using words like "should" and some? don't inspire a lot of confidence
> > that this is the right thing to do. Is there some way to verify that
> > these two conditions are true?  
> 
> Well the i915 code should never call intel_dsi_[pre_]enable without
> first having called intel_dsi_post_disable() which does:
> 
> intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_ASSERT_RESET);
> 
> Already, also this is undoing a recent (4.9 kernel IIRC) change,
> before that the i915 did not call the MIPI_SEQ_ASSERT_RESET
> sequence from the enable path. Also doing this is against the VBT
> spec.
> 
> Regards,
> 
> Hans
> 

So let's try to make the commit message state that.  Using what you
just wrote maybe something like:

intel_dsi_post_disable(), which does the MIPI_SEQ_ASSERT_RESET,
will always be called at some point before intel_dsi_pre_enable()
making the MIPI_SEQ_ASSERT_RESET in intel_dsi_pre_enable() redundent. 

In addition, calling MIPI_SEQ_ASSERT_RESET in the enable path goes
against the VBT spec.

With the commit message updated the change looks to be correct.


> 
> 
> >  
> >> ---
> >>  drivers/gpu/drm/i915/intel_dsi.c | 1 -
> >>  1 file changed, 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
> >> b/drivers/gpu/drm/i915/intel_dsi.c
> >> index 78d5884..4ebf308 100644
> >> --- a/drivers/gpu/drm/i915/intel_dsi.c
> >> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> >> @@ -669,7 +669,6 @@ static void intel_dsi_pre_enable(struct intel_encoder 
> >> *encoder,
> >>/* put device in ready state */
> >>intel_dsi_device_ready(encoder);
> >>
> >> -  intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_ASSERT_RESET);
> >>intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_POWER_ON);
> >>intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_DEASSERT_RESET);
> >>intel_dsi_exec_vbt_sequence(intel_dsi, MIPI_SEQ_INIT_OTP);  
> >
> >
> >  



-- 
--
Bob Paauwe  
bob.j.paa...@intel.com
IOTG / PED Software Organization
Intel Corp.  Folsom, CA
(916) 356-6193

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

Re: [Intel-gfx] [PATCH v2 4/4] drm: handle override edid and firmware EDID at drm_do_get_edid() level

[Ville Syrjälä]

On Mon, Feb 27, 2017 at 05:19:21PM +0100, Daniel Vetter wrote:
> On Mon, Feb 27, 2017 at 05:09:44PM +0200, Ville Syrjälä wrote:
> > On Sun, Feb 26, 2017 at 10:22:42PM +0100, Daniel Vetter wrote:
> > > On Fri, Feb 17, 2017 at 05:20:54PM +0200, Jani Nikula wrote:
> > > > Handle debugfs override edid and firmware edid at the low level to
> > > > transparently and completely replace the real edid. Previously, we
> > > > practically only used the modes from the override EDID, and none of the
> > > > other data. This also prevents actual EDID reads when the EDID is to be
> > > > overridden, but retains the DDC probe.
> > > > 
> > > > Move firmware EDID loading from helper to core, as the functionality
> > > > moves to lower level as well. This will result in a change of module
> > > > parameter from drm_kms_helper.edid_firmware to drm.edid_firmware, which
> > > > arguably makes more sense anyway.
> > > > 
> > > > FIXME: validate override edid, deduplicate firmware edid validation.
> > > > 
> > > > v2: move firmware loading to core
> > > > 
> > > > Signed-off-by: Jani Nikula 
> > > > ---
> > > >  drivers/gpu/drm/Kconfig|  2 +-
> > > >  drivers/gpu/drm/Makefile   |  2 +-
> > > >  drivers/gpu/drm/drm_edid.c | 15 +++
> > > >  drivers/gpu/drm/drm_probe_helper.c | 19 +--
> > > >  4 files changed, 18 insertions(+), 20 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> > > > index 90bc65d07a35..f983ef60299c 100644
> > > > --- a/drivers/gpu/drm/Kconfig
> > > > +++ b/drivers/gpu/drm/Kconfig
> > > > @@ -101,7 +101,7 @@ config DRM_FBDEV_EMULATION
> > > >  
> > > >  config DRM_LOAD_EDID_FIRMWARE
> > > > bool "Allow to specify an EDID data set instead of probing for 
> > > > it"
> > > > -   depends on DRM_KMS_HELPER
> > > > +   depends on DRM
> > > > help
> > > >   Say Y here, if you want to use EDID data to be loaded from the
> > > >   /lib/firmware directory or one of the provided built-in
> > > > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> > > > index 92de3991fa56..a10ac095608f 100644
> > > > --- a/drivers/gpu/drm/Makefile
> > > > +++ b/drivers/gpu/drm/Makefile
> > > > @@ -27,13 +27,13 @@ drm-$(CONFIG_DRM_PANEL) += drm_panel.o
> > > >  drm-$(CONFIG_OF) += drm_of.o
> > > >  drm-$(CONFIG_AGP) += drm_agpsupport.o
> > > >  drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
> > > > +drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
> > > >  
> > > >  drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o 
> > > > drm_probe_helper.o \
> > > > drm_plane_helper.o drm_dp_mst_topology.o 
> > > > drm_atomic_helper.o \
> > > > drm_kms_helper_common.o drm_dp_dual_mode_helper.o \
> > > > drm_simple_kms_helper.o drm_modeset_helper.o
> > > >  
> > > > -drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
> > > >  drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
> > > >  drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
> > > >  drm_kms_helper-$(CONFIG_DRM_DP_AUX_CHARDEV) += drm_dp_aux_dev.o
> > > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > > > index e1743ab276dc..4007998d5ce3 100644
> > > > --- a/drivers/gpu/drm/drm_edid.c
> > > > +++ b/drivers/gpu/drm/drm_edid.c
> > > > @@ -1309,6 +1309,10 @@ static void connector_bad_edid(struct 
> > > > drm_connector *connector,
> > > >   * level, drivers must make all reasonable efforts to expose it as an 
> > > > I2C
> > > >   * adapter and use drm_get_edid() instead of abusing this function.
> > > >   *
> > > > + * The EDID may be overridden using debugfs override_edid or firmare 
> > > > EDID
> > > > + * (drm_load_edid_firmware()), in this priority order. Having either 
> > > > of them
> > > > + * bypasses actual EDID reads.
> > > > + *
> > > >   * Return: Pointer to valid EDID or NULL if we couldn't find any.
> > > >   */
> > > >  struct edid *drm_do_get_edid(struct drm_connector *connector,
> > > > @@ -1318,6 +1322,17 @@ struct edid *drm_do_get_edid(struct 
> > > > drm_connector *connector,
> > > >  {
> > > > int i, j = 0, valid_extensions = 0;
> > > > u8 *edid, *new;
> > > > +   struct edid *override = NULL;
> > > > +
> > > > +   if (connector->override_edid)
> > > > +   override = drm_edid_duplicate((const struct edid *)
> > > > + 
> > > > connector->edid_blob_ptr->data);
> > > > +
> > > > +   if (!override)
> > > > +   override = drm_load_edid_firmware(connector);
> > > > +
> > > > +   if (!IS_ERR_OR_NULL(override))
> > > > +   return override;
> > > >  
> > > > if ((edid = kmalloc(EDID_LENGTH, GFP_KERNEL)) == NULL)
> > > > return NULL;
> > > > diff --git a/drivers/gpu/drm/drm_probe_helper.c 
> > > > b/drivers/gpu/drm/drm_probe_helper.c
> > > 

Re: [Intel-gfx] [PATCH] drm/i915: Distinguish between timeout and error in sideband transactions

[Jani Nikula]

On Thu, 23 Feb 2017, Chris Wilson  wrote:
> After initiating a sideband transaction, we only want to wait for the
> transaction to become idle. If, as we are, we wait for both the busy
> and error flag to clear, if an error is raised we just spin until the
> timeout. Once the hw is idle, we can then check to see if the hw flagged
> an error, and report it distinctly.
>
> Signed-off-by: Chris Wilson 
> Cc: Jani Nikula 

Much better indeed.

Reviewed-by: Jani Nikula 

(The pedantic nitpick is that response status is really two bits, and
you could read them both and fail if they're not zero. But meh.)

> ---
>  drivers/gpu/drm/i915/intel_sideband.c | 20 
>  1 file changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_sideband.c 
> b/drivers/gpu/drm/i915/intel_sideband.c
> index 9f782b5eb6e6..41712ea9f5f8 100644
> --- a/drivers/gpu/drm/i915/intel_sideband.c
> +++ b/drivers/gpu/drm/i915/intel_sideband.c
> @@ -216,6 +216,7 @@ u32 intel_sbi_read(struct drm_i915_private *dev_priv, u16 
> reg,
>   }
>  
>   I915_WRITE(SBI_ADDR, (reg << 16));
> + I915_WRITE(SBI_DATA, 0);
>  
>   if (destination == SBI_ICLK)
>   value = SBI_CTL_DEST_ICLK | SBI_CTL_OP_CRRD;
> @@ -225,10 +226,15 @@ u32 intel_sbi_read(struct drm_i915_private *dev_priv, 
> u16 reg,
>  
>   if (intel_wait_for_register(dev_priv,
>   SBI_CTL_STAT,
> - SBI_BUSY | SBI_RESPONSE_FAIL,
> + SBI_BUSY,
>   0,
>   100)) {
> - DRM_ERROR("timeout waiting for SBI to complete read 
> transaction\n");
> + DRM_ERROR("timeout waiting for SBI to complete read\n");
> + return 0;
> +
> + }
> + if (I915_READ(SBI_CTL_STAT) & SBI_RESPONSE_FAIL) {
> + DRM_ERROR("error during SBI read of reg %x\n", reg);
>   return 0;
>   }
>  
> @@ -260,10 +266,16 @@ void intel_sbi_write(struct drm_i915_private *dev_priv, 
> u16 reg, u32 value,
>  
>   if (intel_wait_for_register(dev_priv,
>   SBI_CTL_STAT,
> - SBI_BUSY | SBI_RESPONSE_FAIL,
> + SBI_BUSY,
>   0,
>   100)) {
> - DRM_ERROR("timeout waiting for SBI to complete write 
> transaction\n");
> + DRM_ERROR("timeout waiting for SBI to complete write\n");
> + return;
> + }
> +
> + if (I915_READ(SBI_CTL_STAT) & SBI_RESPONSE_FAIL) {
> + DRM_ERROR("error during SBI write of %x to reg %x\n",
> +   value, reg);
>   return;
>   }
>  }

-- 
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 v2 4/4] drm: handle override edid and firmware EDID at drm_do_get_edid() level

[Daniel Vetter]

On Mon, Feb 27, 2017 at 05:09:44PM +0200, Ville Syrjälä wrote:
> On Sun, Feb 26, 2017 at 10:22:42PM +0100, Daniel Vetter wrote:
> > On Fri, Feb 17, 2017 at 05:20:54PM +0200, Jani Nikula wrote:
> > > Handle debugfs override edid and firmware edid at the low level to
> > > transparently and completely replace the real edid. Previously, we
> > > practically only used the modes from the override EDID, and none of the
> > > other data. This also prevents actual EDID reads when the EDID is to be
> > > overridden, but retains the DDC probe.
> > > 
> > > Move firmware EDID loading from helper to core, as the functionality
> > > moves to lower level as well. This will result in a change of module
> > > parameter from drm_kms_helper.edid_firmware to drm.edid_firmware, which
> > > arguably makes more sense anyway.
> > > 
> > > FIXME: validate override edid, deduplicate firmware edid validation.
> > > 
> > > v2: move firmware loading to core
> > > 
> > > Signed-off-by: Jani Nikula 
> > > ---
> > >  drivers/gpu/drm/Kconfig|  2 +-
> > >  drivers/gpu/drm/Makefile   |  2 +-
> > >  drivers/gpu/drm/drm_edid.c | 15 +++
> > >  drivers/gpu/drm/drm_probe_helper.c | 19 +--
> > >  4 files changed, 18 insertions(+), 20 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> > > index 90bc65d07a35..f983ef60299c 100644
> > > --- a/drivers/gpu/drm/Kconfig
> > > +++ b/drivers/gpu/drm/Kconfig
> > > @@ -101,7 +101,7 @@ config DRM_FBDEV_EMULATION
> > >  
> > >  config DRM_LOAD_EDID_FIRMWARE
> > >   bool "Allow to specify an EDID data set instead of probing for it"
> > > - depends on DRM_KMS_HELPER
> > > + depends on DRM
> > >   help
> > > Say Y here, if you want to use EDID data to be loaded from the
> > > /lib/firmware directory or one of the provided built-in
> > > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> > > index 92de3991fa56..a10ac095608f 100644
> > > --- a/drivers/gpu/drm/Makefile
> > > +++ b/drivers/gpu/drm/Makefile
> > > @@ -27,13 +27,13 @@ drm-$(CONFIG_DRM_PANEL) += drm_panel.o
> > >  drm-$(CONFIG_OF) += drm_of.o
> > >  drm-$(CONFIG_AGP) += drm_agpsupport.o
> > >  drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
> > > +drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
> > >  
> > >  drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o 
> > > \
> > >   drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
> > >   drm_kms_helper_common.o drm_dp_dual_mode_helper.o \
> > >   drm_simple_kms_helper.o drm_modeset_helper.o
> > >  
> > > -drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
> > >  drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
> > >  drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
> > >  drm_kms_helper-$(CONFIG_DRM_DP_AUX_CHARDEV) += drm_dp_aux_dev.o
> > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > > index e1743ab276dc..4007998d5ce3 100644
> > > --- a/drivers/gpu/drm/drm_edid.c
> > > +++ b/drivers/gpu/drm/drm_edid.c
> > > @@ -1309,6 +1309,10 @@ static void connector_bad_edid(struct 
> > > drm_connector *connector,
> > >   * level, drivers must make all reasonable efforts to expose it as an I2C
> > >   * adapter and use drm_get_edid() instead of abusing this function.
> > >   *
> > > + * The EDID may be overridden using debugfs override_edid or firmare EDID
> > > + * (drm_load_edid_firmware()), in this priority order. Having either of 
> > > them
> > > + * bypasses actual EDID reads.
> > > + *
> > >   * Return: Pointer to valid EDID or NULL if we couldn't find any.
> > >   */
> > >  struct edid *drm_do_get_edid(struct drm_connector *connector,
> > > @@ -1318,6 +1322,17 @@ struct edid *drm_do_get_edid(struct drm_connector 
> > > *connector,
> > >  {
> > >   int i, j = 0, valid_extensions = 0;
> > >   u8 *edid, *new;
> > > + struct edid *override = NULL;
> > > +
> > > + if (connector->override_edid)
> > > + override = drm_edid_duplicate((const struct edid *)
> > > +   connector->edid_blob_ptr->data);
> > > +
> > > + if (!override)
> > > + override = drm_load_edid_firmware(connector);
> > > +
> > > + if (!IS_ERR_OR_NULL(override))
> > > + return override;
> > >  
> > >   if ((edid = kmalloc(EDID_LENGTH, GFP_KERNEL)) == NULL)
> > >   return NULL;
> > > diff --git a/drivers/gpu/drm/drm_probe_helper.c 
> > > b/drivers/gpu/drm/drm_probe_helper.c
> > > index 358957118ca9..871326cbc465 100644
> > > --- a/drivers/gpu/drm/drm_probe_helper.c
> > > +++ b/drivers/gpu/drm/drm_probe_helper.c
> > > @@ -199,8 +199,6 @@ drm_connector_detect(struct drm_connector *connector, 
> > > bool force)
> > >   *drm_mode_probed_add(). New modes start their life with status as 
> > > OK.
> > >   *Modes are added from a single source using the following priority 
> > > order.
> > >   *
> 

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/3] drm/i915: Remove redundant TLB invalidate on switching contexts

[Chris Wilson]

On Mon, Feb 27, 2017 at 03:52:12PM -, Patchwork wrote:
> == Series Details ==
> 
> Series: series starting with [CI,1/3] drm/i915: Remove redundant TLB 
> invalidate on switching contexts
> URL   : https://patchwork.freedesktop.org/series/20313/
> State : success
> 
> == Summary ==
> 
> Series 20313v1 Series without cover letter
> https://patchwork.freedesktop.org/api/1.0/series/20313/revisions/1/mbox/
> 
> fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11 
> fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39 
> fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19 
> fi-bxt-t5700 total:108  pass:95   dwarn:0   dfail:0   fail:0   skip:12 
> fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27 
> fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31 
> fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
> fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
> fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50 
> fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
> fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
> fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
> fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
> fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17 
> fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18 
> fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
> fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28 
> fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29 
> 
> f76e5eca8c2a46cbd0203d32842bca6ce0ec16ef drm-tip: 2017y-02m-27d-13h-20m-25s 
> UTC integration manifest
> 4106ba6 drm/i915: Reduce context alignment
> fc2a90b drm/i915: Remove redundant TLB invalidate on switching ppgtt
> a2956c8 drm/i915: Remove redundant TLB invalidate on switching contexts

Thanks for the review on these 3, pushed.
-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] [PULL] drm-misc-next-fixes

[Daniel Vetter]

Hi Dave,

drm-misc-next-fixes-2017-02-27:
Misc fixes for the 4.11 merge window.

- vmwgfx drm_control node compat patch
- rockchip fixes
- compat32 support for dma-buf ioctl (cc: stable ofc, since this is a
  massive fumble. oops)

Nothing major outstanding afaik.

Cheers, Daniel


The following changes since commit 2220fc1ab363e6fab1f321430d69be17a8b92bd7:

  uapi: add missing install of dma-buf.h (2017-02-14 22:45:16 +0100)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-misc tags/drm-misc-next-fixes-2017-02-27

for you to fetch changes up to 888022c0473d079bff9b47fb50434b1f20f8f37f:

  dma-buf: add support for compat ioctl (2017-02-27 17:23:47 +0530)


Misc fixes for the 4.11 merge window.

- vmwgfx drm_control node compat patch
- rockchip fix
- compat32 support for dma-buf ioctl (cc: stable ofc, since this is a
  massive fumble. oops)


Arnd Bergmann (1):
  drm/rockchip: add extcon dependency for DP

Christophe JAILLET (1):
  drm/rockchip: cdn-dp: Fix error handling

Marek Szyprowski (1):
  dma-buf: add support for compat ioctl

Shawn Guo (1):
  drm: zte: fix static checker warning on variable 'fmt'

Thomas Hellstrom (1):
  drm/vmwgfx: Work around drm removal of control nodes

 drivers/dma-buf/dma-buf.c  |  3 +++
 drivers/gpu/drm/rockchip/Kconfig   |  1 +
 drivers/gpu/drm/rockchip/cdn-dp-core.c |  4 +++-
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 11 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h|  4 ++--
 drivers/gpu/drm/zte/zx_plane.c |  4 ++--
 6 files changed, 21 insertions(+), 6 deletions(-)

-- 
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 series starting with [CI,1/3] drm/i915: Remove redundant TLB invalidate on switching contexts

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/3] drm/i915: Remove redundant TLB invalidate 
on switching contexts
URL   : https://patchwork.freedesktop.org/series/20313/
State : success

== Summary ==

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:108  pass:95   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29 

f76e5eca8c2a46cbd0203d32842bca6ce0ec16ef drm-tip: 2017y-02m-27d-13h-20m-25s UTC 
integration manifest
4106ba6 drm/i915: Reduce context alignment
fc2a90b drm/i915: Remove redundant TLB invalidate on switching ppgtt
a2956c8 drm/i915: Remove redundant TLB invalidate on switching contexts

== Logs ==

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

Re: [Intel-gfx] [PATCH 07/10] drm/i915/guc: Simplify intel_guc_init_hw()

[Arkadiusz Hiler]

On Fri, Feb 24, 2017 at 06:26:10PM +0100, Michal Wajdeczko wrote:
> On Fri, Feb 24, 2017 at 04:40:01PM +0100, Arkadiusz Hiler wrote:
> > Current version of intel_guc_init_hw() does a lot:
> >  - cares about submission
> >  - loads huc
> >  - implement WA
> > 
> > This change offloads some of the logic to intel_uc_init_hw(), which now
> > cares about the above.
> > 
> > v2: rename guc_hw_reset and fix typo in define name (M. Wajdeczko)
> > v3: rename once again
> > v4: remove spurious comments and add some style (J. Lahtinen)
> > 
> > Cc: Anusha Srivatsa 
> > Cc: Michal Winiarski 
> > Cc: Michal Wajdeczko 
> > Cc: Daniele Ceraolo Spurio 
> > Cc: Joonas Lahtinen 
> > Signed-off-by: Arkadiusz Hiler 
> > ---
> >  drivers/gpu/drm/i915/i915_gem.c |   2 +-
> >  drivers/gpu/drm/i915/intel_guc_loader.c | 144 
> > 
> >  drivers/gpu/drm/i915/intel_uc.c | 110 
> >  drivers/gpu/drm/i915/intel_uc.h |   3 +
> >  4 files changed, 128 insertions(+), 131 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index 5b36524..8943c4e 100644
> > @@ -443,42 +425,24 @@ int intel_guc_init_hw(struct drm_i915_private 
> > *dev_priv)
> >  {
> 
> > -   /* Loading forbidden, or no firmware to load? */
> > -   if (!i915.enable_guc_loading) {
> > -   err = 0;
> > -   goto fail;
> > -   } else if (fw_path == NULL) {
> > -   /* Device is known to have no uCode (e.g. no GuC) */
> > -   err = -ENXIO;
> > -   goto fail;
> > +   if (!fw_path) {
> > +   return -ENXIO;
> > } else if (*fw_path == '\0') {
> 
> Hmm, is this case still possible?

In this revision - yes, but unlikely.

HAS_GUC() is true but firmware for the device is not known (see
init_fw()). I think that the initial flow was designed in this case in
mind.

> > -   /* Device has a GuC but we don't know what f/w to load? */
> > WARN(1, "No GuC firmware known for this platform!\n");
> > -   err = -ENODEV;
> > -   goto fail;
> > +   return -ENODEV;
> > }
> >  
> > -   /* Fetch failed, or already fetched but failed to load? */
> > -   if (guc_fw->fetch_status != INTEL_UC_FIRMWARE_SUCCESS) {
> > -   err = -EIO;
> > -   goto fail;
> > -   } else if (guc_fw->load_status == INTEL_UC_FIRMWARE_FAIL) {
> > -   err = -ENOEXEC;
> > -   goto fail;
> > -   }
> > -
> > -   guc_interrupts_release(dev_priv);
> > -   gen9_reset_guc_interrupts(dev_priv);
> > -
> > -   /* We need to notify the guc whenever we change the GGTT */
> > -   i915_ggtt_enable_guc(dev_priv);
> > +   if (guc_fw->fetch_status != INTEL_UC_FIRMWARE_SUCCESS)
> > +   return -EIO;
> > +   else if (guc_fw->load_status == INTEL_UC_FIRMWARE_FAIL)
> > +   return -ENOEXEC;
> 
> Hmm, it looks like you're checking for load failure here, but actual
> load is about to start below ? Did I missed something ?

The status FIRMWARE_FAIL is not used at all in the GuC path (HuC) uses
it. Noted down to give it a closer look.

The check is gone, as it does not make sense, thanks.

> > guc_fw->load_status = INTEL_UC_FIRMWARE_PENDING;
> 
> I guess this status can be set in guc_ucode_xfer() as it uses guc_fw object.

> >  
> > @@ -486,104 +450,24 @@ int intel_guc_init_hw(struct drm_i915_private 
> > *dev_priv)
> > intel_uc_fw_status_repr(guc_fw->fetch_status),
> > intel_uc_fw_status_repr(guc_fw->load_status));
> >  
> > -   err = i915_guc_submission_init(dev_priv);
> > -   if (err)
> > -   goto fail;
> > -
> > /*
> >  * WaEnableuKernelHeaderValidFix:skl,bxt
> >  * For BXT, this is only upto B0 but below WA is required for later
> >  * steppings also so this is extended as well.
> >  */
> 
> Rebase issue?

Yeah. I've streamlined the whole thing to be:

--
int attempts;
const int guc_wa_hash_check_not_set_attempts = 3;



/* WaEnableuKernelHeaderValidFix:skl */
/* WaEnableGuCBootHashCheckNotSet:skl,bxt,kbl */
if (IS_GEN9(dev_priv))
attempts = guc_wa_hash_check_not_set_attempts;
else
attempts = 1;

while (attempts--) ...
--


and dropped the WA comments in the guc_init_hw()



> > +int intel_uc_init_hw(struct drm_i915_private *dev_priv)
> > +{
> 
> > +fail:
> > +   /*
> > +* We've failed to load the firmware :(
> > +*
> > +* Decide whether to disable GuC submission and fall back to
> > +* execlist mode, and whether to hide the error by returning
> > +* zero or to return -EIO, which the caller will treat as a
> > +* nonfatal error (i.e. it doesn't prevent driver load, but
> > +* marks the GPU as 

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/3] drm/i915: Start splitting out i915_gem_object routines

[Patchwork]

== Series Details ==

Series: series starting with [1/3] drm/i915: Start splitting out 
i915_gem_object routines
URL   : https://patchwork.freedesktop.org/series/20312/
State : warning

== Summary ==

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

Test kms_force_connector_basic:
Subgroup force-connector-state:
pass   -> SKIP   (fi-ivb-3520m)
Subgroup force-edid:
pass   -> SKIP   (fi-ivb-3520m)
Subgroup force-load-detect:
pass   -> SKIP   (fi-ivb-3520m)
Subgroup prune-stale-modes:
pass   -> SKIP   (fi-ivb-3520m)

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:108  pass:95   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:278  pass:256  dwarn:0   dfail:0   fail:0   skip:22 
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29 

f76e5eca8c2a46cbd0203d32842bca6ce0ec16ef drm-tip: 2017y-02m-27d-13h-20m-25s UTC 
integration manifest
2f0647e drm/i915: Exercise backing storage of mock gem objects
b8842c2 drm/i915: Start splitting out i915_gem_object routines

== Logs ==

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

Re: [Intel-gfx] [PATCH 8/9] drm/i915: Implement .get_format_info() hook for CCS

[Ville Syrjälä]

On Sun, Feb 26, 2017 at 02:41:50PM -0800, Chad Versace wrote:
> On Wed 04 Jan 2017, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > SKL+ display engine can scan out certain kinds of compressed surfaces
> > produced by the render engine. This involved telling the display engine
> > the location of the color control surfae (CCS) which describes which
> > parts of the main surface are compressed and which are not. The location
> > of CCS is provided by userspace as just another plane with its own offset.
> > 
> > By providing our own format information for the CCS formats, we should
> > be able to make framebuffer_check() do the right thing for the CCS
> > surface as well.
> > 
> > Note that we'll return the same format info for both Y and Yf tiled
> > format as that's what happens with the non-CCS Y vs. Yf as well. If
> > desired, we could potentially return a unique pointer for each
> > pixel_format+tiling+ccs combination, in which case we immediately be
> > able to tell if any of that stuff changed by just comparing the
> > pointers. But that does sound a bit wasteful space wise.
> > 
> > v2: Drop the 'dev' argument from the hook
> > v3: Include the description of the CCS surface layout
> > 
> > Cc: Vandana Kannan 
> > Cc: Daniel Vetter 
> > Cc: Ben Widawsky 
> > Cc: Jason Ekstrand 
> > Reviewed-by: Ben Widawsky 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 36 ++
> >  include/uapi/drm/drm_fourcc.h| 49 
> > 
> >  2 files changed, 85 insertions(+)
> 
> 
> > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> > index 9e1bb7fabcde..4581e3d41e5c 100644
> > --- a/include/uapi/drm/drm_fourcc.h
> > +++ b/include/uapi/drm/drm_fourcc.h
> > @@ -230,6 +230,55 @@ extern "C" {
> >  #define I915_FORMAT_MOD_Yf_TILED fourcc_mod_code(INTEL, 3)
> >  
> >  /*
> > + * Intel color control surface (CCS) for render compression
> > + *
> > + * The framebuffer format must be one of the 8:8:8:8 RGB formats,
> > + * the main surface will be plane index 0 and will be Y/Yf-tiled,
> > + * the CCS will be plane index 1.
> > + *
> 
> The paragraph below is...
> 
> > + * Each byte of CCS contains 4 pairs of bits, with each pair of bits
> > + * matching an area of 8x4 pixels of the main surface. Which would seem
> > + * to match 2 cachelines containing 4x4 pixels each. The pairs bits within
> > + * the byte form a 2x2 grid, which thus matches a 16x8 pixel area of the
> > + * main surface. This is the 2x2 pattern the bits form (0=lsb, 7=msb):
> > + * ---
> > + * | 01 | 23 |
> > + *  --
> > + * | 45 | 67 |
> > + * ---
> 
> ...almost correct. The hw docs state that each bit-pair of the CCS maps
> cacheline-pair, horizontally adjacent in the Y tile, of the primary surface. 
> As
> a consequence, the remainder of the above paragraph is correct for 32-bit
> formats, but not others.

Which is why the comment says at the very top that the fb needs to
use a 8:8:8:8 format. IIRC that's the only thing the hardware supports.

> 
> This is not a nitpick, because Vulkan and EGL users may want to share
> dma_bufs with a fat format like R32G32B32A32_UNORM, and want to have CCS
> enabled when possible. As long as the users use the dma_buf only the 3D
> engine, and don't submit it to KMS, it's all safe.
> 
> For those users, we should document the bit-pair/cacheline-pair relationship
> correctly. And then preface the following detailed explanation and nice ascii
> diagrams by saying "this applies only to the 32-bit formats".
> 
> Here's the relevant PRM quote:
> 
>  The Color Control Surface (CCS) contains the compression status
>  of the cache-line pairs. The compression state of the cache-line
>  pair is specified by 2 bits in the CCS.  Each CCS cache-line
>  represents an area on the main surface of 16x16 sets of 128 byte
>  Y-tiled cache-line-pairs. CCS is always Y tiled.
> 
> See this Mesa comment for more details:
> https://cgit.freedesktop.org/mesa/mesa/tree/src/intel/isl/isl.c?h=17.0#n211
> 
> > + * Actually only the lower bit of the pair seems to have any effect.
> > + * No idea why. 0 in the lower bit would seem to mean not compressed,
> > + * and 1 is compressed.  The interpreation of the main surface data
> > + * when the block is marked compressed is unknown as of now.
> 
> If I recall correctly (it's been several months since I inspected the
> bits), the high bit is actually significant. Bit pattern 11 means that
> the data in primary surface's cacheline-pair is invalid; the 3D engine
> interprets the color of all pixels in that cacheline-pair to be the
> clear color stored in RENDER_SURFACE_STATE. Before the display engine
> can consume the surface, userspace is required to do a 

Re: [Intel-gfx] [PATCH v2 4/4] drm: handle override edid and firmware EDID at drm_do_get_edid() level

[Ville Syrjälä]

On Sun, Feb 26, 2017 at 10:22:42PM +0100, Daniel Vetter wrote:
> On Fri, Feb 17, 2017 at 05:20:54PM +0200, Jani Nikula wrote:
> > Handle debugfs override edid and firmware edid at the low level to
> > transparently and completely replace the real edid. Previously, we
> > practically only used the modes from the override EDID, and none of the
> > other data. This also prevents actual EDID reads when the EDID is to be
> > overridden, but retains the DDC probe.
> > 
> > Move firmware EDID loading from helper to core, as the functionality
> > moves to lower level as well. This will result in a change of module
> > parameter from drm_kms_helper.edid_firmware to drm.edid_firmware, which
> > arguably makes more sense anyway.
> > 
> > FIXME: validate override edid, deduplicate firmware edid validation.
> > 
> > v2: move firmware loading to core
> > 
> > Signed-off-by: Jani Nikula 
> > ---
> >  drivers/gpu/drm/Kconfig|  2 +-
> >  drivers/gpu/drm/Makefile   |  2 +-
> >  drivers/gpu/drm/drm_edid.c | 15 +++
> >  drivers/gpu/drm/drm_probe_helper.c | 19 +--
> >  4 files changed, 18 insertions(+), 20 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> > index 90bc65d07a35..f983ef60299c 100644
> > --- a/drivers/gpu/drm/Kconfig
> > +++ b/drivers/gpu/drm/Kconfig
> > @@ -101,7 +101,7 @@ config DRM_FBDEV_EMULATION
> >  
> >  config DRM_LOAD_EDID_FIRMWARE
> > bool "Allow to specify an EDID data set instead of probing for it"
> > -   depends on DRM_KMS_HELPER
> > +   depends on DRM
> > help
> >   Say Y here, if you want to use EDID data to be loaded from the
> >   /lib/firmware directory or one of the provided built-in
> > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> > index 92de3991fa56..a10ac095608f 100644
> > --- a/drivers/gpu/drm/Makefile
> > +++ b/drivers/gpu/drm/Makefile
> > @@ -27,13 +27,13 @@ drm-$(CONFIG_DRM_PANEL) += drm_panel.o
> >  drm-$(CONFIG_OF) += drm_of.o
> >  drm-$(CONFIG_AGP) += drm_agpsupport.o
> >  drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
> > +drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
> >  
> >  drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
> > drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
> > drm_kms_helper_common.o drm_dp_dual_mode_helper.o \
> > drm_simple_kms_helper.o drm_modeset_helper.o
> >  
> > -drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
> >  drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
> >  drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
> >  drm_kms_helper-$(CONFIG_DRM_DP_AUX_CHARDEV) += drm_dp_aux_dev.o
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index e1743ab276dc..4007998d5ce3 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -1309,6 +1309,10 @@ static void connector_bad_edid(struct drm_connector 
> > *connector,
> >   * level, drivers must make all reasonable efforts to expose it as an I2C
> >   * adapter and use drm_get_edid() instead of abusing this function.
> >   *
> > + * The EDID may be overridden using debugfs override_edid or firmare EDID
> > + * (drm_load_edid_firmware()), in this priority order. Having either of 
> > them
> > + * bypasses actual EDID reads.
> > + *
> >   * Return: Pointer to valid EDID or NULL if we couldn't find any.
> >   */
> >  struct edid *drm_do_get_edid(struct drm_connector *connector,
> > @@ -1318,6 +1322,17 @@ struct edid *drm_do_get_edid(struct drm_connector 
> > *connector,
> >  {
> > int i, j = 0, valid_extensions = 0;
> > u8 *edid, *new;
> > +   struct edid *override = NULL;
> > +
> > +   if (connector->override_edid)
> > +   override = drm_edid_duplicate((const struct edid *)
> > + connector->edid_blob_ptr->data);
> > +
> > +   if (!override)
> > +   override = drm_load_edid_firmware(connector);
> > +
> > +   if (!IS_ERR_OR_NULL(override))
> > +   return override;
> >  
> > if ((edid = kmalloc(EDID_LENGTH, GFP_KERNEL)) == NULL)
> > return NULL;
> > diff --git a/drivers/gpu/drm/drm_probe_helper.c 
> > b/drivers/gpu/drm/drm_probe_helper.c
> > index 358957118ca9..871326cbc465 100644
> > --- a/drivers/gpu/drm/drm_probe_helper.c
> > +++ b/drivers/gpu/drm/drm_probe_helper.c
> > @@ -199,8 +199,6 @@ drm_connector_detect(struct drm_connector *connector, 
> > bool force)
> >   *drm_mode_probed_add(). New modes start their life with status as OK.
> >   *Modes are added from a single source using the following priority 
> > order.
> >   *
> > - *- debugfs 'override_edid' (used for testing only)
> > - *- firmware EDID (drm_load_edid_firmware())
> >   *- _connector_helper_funcs.get_modes vfunc
> >   *- if the connector status is connector_status_connected, standard

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v5,1/4] drm/i915: Report both waiters and success from intel_engine_wakeup()

[Chris Wilson]

On Mon, Feb 27, 2017 at 02:52:27PM -, Patchwork wrote:
> == Series Details ==
> 
> Series: series starting with [v5,1/4] drm/i915: Report both waiters and 
> success from intel_engine_wakeup()
> URL   : https://patchwork.freedesktop.org/series/20310/
> State : failure
> 
> == Summary ==
> 
> Series 20310v1 Series without cover letter
> https://patchwork.freedesktop.org/api/1.0/series/20310/revisions/1/mbox/
> 
> Test gvt_basic:
> Subgroup invalid-placeholder-test:
> skip   -> INCOMPLETE (fi-hsw-4770r)

CI lost communication with the host?
-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: failure for series starting with [v5,1/4] drm/i915: Report both waiters and success from intel_engine_wakeup()

[Patchwork]

== Series Details ==

Series: series starting with [v5,1/4] drm/i915: Report both waiters and success 
from intel_engine_wakeup()
URL   : https://patchwork.freedesktop.org/series/20310/
State : failure

== Summary ==

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

Test gvt_basic:
Subgroup invalid-placeholder-test:
skip   -> INCOMPLETE (fi-hsw-4770r)

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:108  pass:95   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:15 
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29 

f76e5eca8c2a46cbd0203d32842bca6ce0ec16ef drm-tip: 2017y-02m-27d-13h-20m-25s UTC 
integration manifest
c311b6b drm/i915: Delay disabling the user interrupt for breadcrumbs
980339f drm/i915: Defer enabling hangcheck to the first fake breadcrumb 
interrupt
87cda8e drm/i915: Signal first fence from irq handler if complete
8c2c5a6 drm/i915: Report both waiters and success from intel_engine_wakeup()

== Logs ==

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

Re: [Intel-gfx] [PATCH] ACPI / bus: Introduce a list of ids for "always present" devices

[Takashi Iwai]

On Mon, 27 Feb 2017 15:25:32 +0100,
Hans de Goede wrote:
> 
> Hi,
> 
> On 27-02-17 14:30, Rafael J. Wysocki wrote:
> > +Mika & Andy
> >
> > On Saturday, February 25, 2017 07:23:28 PM Hans de Goede wrote:
> >> Several cherrytrail devices (all of which ship with windows 10) hide the
> >> lpss pwm controller in ACPI, typically the _STA method looks like this:
> >>
> >> Method (_STA, 0, NotSerialized)  // _STA: Status
> >> {
> >> If (OSID == One)
> >> {
> >> Return (Zero)
> >> }
> >>
> >> Return (0x0F)
> >> }
> >>
> >> Where OSID is some dark magic seen in all cherrytrail ACPI tables making
> >> the machine behave differently depending on which OS it *thinks* it is
> >> booting, this gets set in a number of ways which we cannot control, on
> >> some newer machines it simple hardcoded to "One" aka win10.
> >>
> >> This causes the PWM controller to get hidden, which means Linux cannot
> >> control the backlight level on cht based tablets / laptops.
> >>
> >> Since loading the driver for this does no harm (the only in kernel user
> >> of it is the i915 driver, which will only use it when it needs it), this
> >> commit makes acpi_bus_get_status() always set status to ACPI_STA_DEFAULT
> >> for the 80862288 device, fixing the lack of backlight control.
> >>
> >> Signed-off-by: Hans de Goede 
> >> ---
> >>  drivers/acpi/bus.c | 25 +
> >>  1 file changed, 25 insertions(+)
> >>
> >> diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
> >> index 95855cb..483d4d0 100644
> >> --- a/drivers/acpi/bus.c
> >> +++ b/drivers/acpi/bus.c
> >> @@ -109,11 +109,36 @@ acpi_status acpi_bus_get_status_handle(acpi_handle 
> >> handle,
> >>return status;
> >>  }
> >>
> >> +/*
> >> + * Some ACPI devices are hidden (status == 0x0) in recent BIOS-es because
> >> + * some recent windows drivers bind to one device but poke at multiple
> >> + * devices at the same time, so the others get hidden.
> >> + * We work around this by always reporting ACPI_STA_DEFAULT for these
> >> + * devices. Note this MUST only be done for devices where this is safe.
> >> + */
> >> +static const struct acpi_device_id always_present_device_ids[] = {
> >> +  /*
> >> +   * Cherrytrail pwm directly poked by GPU driver in win10,
> >> +   * but Linux uses a separate pwm driver, harmless if not used.
> >> +   */
> >> +  { "80862288", },
> >> +  { }
> >> +};
> >> +
> >>  int acpi_bus_get_status(struct acpi_device *device)
> >>  {
> >>acpi_status status;
> >>unsigned long long sta;
> >>
> >> +  /* acpi_match_device_ids checks status, so start with default */
> >> +  acpi_set_device_status(device, ACPI_STA_DEFAULT);
> >
> > This shouldn't be done in a "get" routine.
> 
> With this you mean the acpi_match_device_ids() check I assume ?
> (acpi_bus_get_status already calls acpi_set_device_status())
> 
> > Ideally, a scan handler should do that or similar.
> 
> The problem is that drivers/acpi/scan.c: acpi_bus_attach()
> calls acpi_bus_get_status() and if it does not set
> the status to present acpi_bus_attach() exits without bothering
> with attaching scan handlers, which is why I ended up doing this
> here.

Oh, this is interesting, please let me join to the party.

We've hit a similar problem, but for other one: namely, it's INT0002
that is found on a few CHT devices.  It's never bound properly by a
similar reason, where _STA is always zero on Linux:

Method (_STA, 0, NotSerialized)  // _STA: Status
{
If (SOCS <= 0x04)
{
Return (0x0F)
}
Else
{
Return (Zero)
}
}

The device is supposed to be a "virtual GPIO" stuff, and the driver
hasn't been upstreamed from Intel.  Due to the lack of this driver
(and it's binding), the machine gets spurious IRQ#9 after the PM
resume, and it locks up at the second time of PM.


thanks,

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

Re: [Intel-gfx] [PATCH] drm/i915: Remove temporary allocation of dma addresses when rotating

[Tvrtko Ursulin]

On 27/02/2017 10:21, Chris Wilson wrote:

On Mon, Feb 27, 2017 at 10:14:12AM +, Tvrtko Ursulin wrote:


On 27/02/2017 10:06, Chris Wilson wrote:

On Mon, Feb 27, 2017 at 09:55:10AM +, Tvrtko Ursulin wrote:


On 22/02/2017 08:44, Chris Wilson wrote:

I also think that's an argument for improving the general cache rather
than arguing against using it.


Well I wasn't concerned about the cache per se, but about whether it
is completely appropriate (best choice) to use it in this particular
case.

Because as I said before, for 1920x1080x32 we are talking about a
16KiB extremely short lived temporary allocation, vs the similar
size for the sg radix cache. But radix cache sticks around the the
lifetime of obj->mm.pages and it wouldn't otherwise be there since
AFAICS in practice no one really touches frame buffers in a way to
trigger its creation.

Those amounts of memory are not a concern, but again, is the
simplification of the code worth the conceptual downsides mentioned
above? Even if we considered 4K frame buffers, when both allocations
go to ~64KiB, would that change anything? I am not sure, probably
not for me.

So I am still unsure that we should go with this change.


Again, the complaint you have here are general concerns about caching
the mapping. Avoiding using the cache instead of improving the cache
seems the wrong approach.


Depends what kind of improvments to the cache you have in mind. If
you are thinking about size then I disagree, I think it is efficient
enough already. But if you are thinking about the lifetime
management then it is obvious from all that I have written so far
that I would agree with that. Since the core of my "complaint" is
the lifetime mismatch, and not the size.

For lifetime I am not sure what you could do. Exposing the size of
it, with maybe some other bits attached the the object, to the
shrinker I think doesn't make much sense since the sizes are so
small compared to the backing store sizes.

Perhaps you could add an explicit reset of the cache after the
rotation is done with it, but then the only remaining benefit will
be avoiding greater than zero order allocations. I say the only
one.. it would still be a good one. Just have no idea if this level
of cache usage would satisfy you!

Perhaps you could say what kind of optimisation you have in mind to
save me guessing? :)


I was thinking you would like an inactivity timer. Or we could have a
separate shrinker, as that's the principal cache management system.


I thought about the shrinker myself. Even wrote some code to more 
accurately size the objects as part of the existing passes. But as I 
said the contribution of anything object and not backing store is so 
small that, even though it would conceptually be more correct and 
perhaps avoid some marginal over-shrinking, I am not sure it is worth 
doing it. Assuming of course that I got the sizing of the radix tree 
correct! I just hacked something up based on some debug dumping code 
from radix-tree.c.


So the complication is there is no API to get the size of the radix tree 
(or the scatter list table) and we would have to add something, either 
internally to i915, or try and upstream it.


Or we avoid that with your timer idea and just purge all caches which 
haven't been used in a while. Maybe from idle work or something.


But for this immediate patch, would you be happy with adding and 
exporting i915_gem_object_reset_page_iter and calling it after rotation 
is done with accessing the pages? Benefit would be avoidance of 
drm_malloc_gfp if that bothers you most.


Regards,

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

Re: [Intel-gfx] [PATCH] ACPI / bus: Introduce a list of ids for "always present" devices

[Hans de Goede]

Hi,

On 27-02-17 14:30, Rafael J. Wysocki wrote:

+Mika & Andy

On Saturday, February 25, 2017 07:23:28 PM Hans de Goede wrote:

Several cherrytrail devices (all of which ship with windows 10) hide the
lpss pwm controller in ACPI, typically the _STA method looks like this:

Method (_STA, 0, NotSerialized)  // _STA: Status
{
If (OSID == One)
{
Return (Zero)
}

Return (0x0F)
}

Where OSID is some dark magic seen in all cherrytrail ACPI tables making
the machine behave differently depending on which OS it *thinks* it is
booting, this gets set in a number of ways which we cannot control, on
some newer machines it simple hardcoded to "One" aka win10.

This causes the PWM controller to get hidden, which means Linux cannot
control the backlight level on cht based tablets / laptops.

Since loading the driver for this does no harm (the only in kernel user
of it is the i915 driver, which will only use it when it needs it), this
commit makes acpi_bus_get_status() always set status to ACPI_STA_DEFAULT
for the 80862288 device, fixing the lack of backlight control.

Signed-off-by: Hans de Goede 
---
 drivers/acpi/bus.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 95855cb..483d4d0 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -109,11 +109,36 @@ acpi_status acpi_bus_get_status_handle(acpi_handle handle,
return status;
 }

+/*
+ * Some ACPI devices are hidden (status == 0x0) in recent BIOS-es because
+ * some recent windows drivers bind to one device but poke at multiple
+ * devices at the same time, so the others get hidden.
+ * We work around this by always reporting ACPI_STA_DEFAULT for these
+ * devices. Note this MUST only be done for devices where this is safe.
+ */
+static const struct acpi_device_id always_present_device_ids[] = {
+   /*
+* Cherrytrail pwm directly poked by GPU driver in win10,
+* but Linux uses a separate pwm driver, harmless if not used.
+*/
+   { "80862288", },
+   { }
+};
+
 int acpi_bus_get_status(struct acpi_device *device)
 {
acpi_status status;
unsigned long long sta;

+   /* acpi_match_device_ids checks status, so start with default */
+   acpi_set_device_status(device, ACPI_STA_DEFAULT);


This shouldn't be done in a "get" routine.


With this you mean the acpi_match_device_ids() check I assume ?
(acpi_bus_get_status already calls acpi_set_device_status())


Ideally, a scan handler should do that or similar.


The problem is that drivers/acpi/scan.c: acpi_bus_attach()
calls acpi_bus_get_status() and if it does not set
the status to present acpi_bus_attach() exits without bothering
with attaching scan handlers, which is why I ended up doing this
here.


+   if (acpi_match_device_ids(device, always_present_device_ids) == 0) {
+   ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Device [%s] is in always present 
list setting status [%08x]\n",
+ device->pnp.bus_id, ACPI_STA_DEFAULT));


pr_debug() please.  The ACPI_DEBUG_PRINT() stuff is basically for ACPICA
(yes, I know it is used elsewhere and no, it is not a good idea to do that).


Ok, that is easy to fix :)



+   return 0;
+   }
+   acpi_set_device_status(device, 0);
+
status = acpi_bus_get_status_handle(device->handle, );
if (ACPI_FAILURE(status))
return -ENODEV;



Thanks,
Rafael


Regards,

Hans

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

[Intel-gfx] [PATCH 1/2] drm/i915: Stop using RP_DOWN_EI on Baytrail

[Chris Wilson]

On Baytrail, we manually calculate busyness over the evaluation interval
to avoid issues with miscaluations with RC6 enabled. However, it turns
out that the DOWN_EI interrupt generator is completely bust - it
operates in two modes, continuous or never. Neither of which are
conducive to good behaviour. Stop unmask the DOWN_EI interrupt and just
compute everything from the UP_EI which does seem to correspond to the
desired interval.

v2: Fixup gen6_rps_pm_mask() as well

Fixes: 43cf3bf084ba ("drm/i915: Improved w/a for rps on Baytrail")
Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc:  # v4.1+
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h |  2 +-
 drivers/gpu/drm/i915/i915_irq.c | 28 +---
 drivers/gpu/drm/i915/intel_pm.c |  5 +++--
 3 files changed, 13 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9c5b3dd9f6f1..d70bbbd6a5fd 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1366,7 +1366,7 @@ struct intel_gen6_power_mgmt {
unsigned boosts;
 
/* manual wa residency calculations */
-   struct intel_rps_ei up_ei, down_ei;
+   struct intel_rps_ei ei;
 
/*
 * Protects RPS/RC6 register access and PCU communication.
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index bc70e2c451b2..29b10bab38b6 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1050,10 +1050,10 @@ static void vlv_c0_read(struct drm_i915_private 
*dev_priv,
 }
 
 static bool vlv_c0_above(struct drm_i915_private *dev_priv,
-const struct intel_rps_ei *old,
 const struct intel_rps_ei *now,
 int threshold)
 {
+   const struct intel_rps_ei *old = _priv->rps.ei;
u64 time, c0;
unsigned int mul = 100;
 
@@ -1079,8 +1079,7 @@ static bool vlv_c0_above(struct drm_i915_private 
*dev_priv,
 
 void gen6_rps_reset_ei(struct drm_i915_private *dev_priv)
 {
-   vlv_c0_read(dev_priv, _priv->rps.down_ei);
-   dev_priv->rps.up_ei = dev_priv->rps.down_ei;
+   memset(_priv->rps.ei, 0, sizeof(dev_priv->rps.ei));
 }
 
 static u32 vlv_wa_c0_ei(struct drm_i915_private *dev_priv, u32 pm_iir)
@@ -1088,28 +1087,19 @@ static u32 vlv_wa_c0_ei(struct drm_i915_private 
*dev_priv, u32 pm_iir)
struct intel_rps_ei now;
u32 events = 0;
 
-   if ((pm_iir & (GEN6_PM_RP_DOWN_EI_EXPIRED | GEN6_PM_RP_UP_EI_EXPIRED)) 
== 0)
+   if ((pm_iir & GEN6_PM_RP_UP_EI_EXPIRED) == 0)
return 0;
 
vlv_c0_read(dev_priv, );
if (now.cz_clock == 0)
return 0;
 
-   if (pm_iir & GEN6_PM_RP_DOWN_EI_EXPIRED) {
-   if (!vlv_c0_above(dev_priv,
- _priv->rps.down_ei, ,
- dev_priv->rps.down_threshold))
-   events |= GEN6_PM_RP_DOWN_THRESHOLD;
-   dev_priv->rps.down_ei = now;
-   }
+   if (vlv_c0_above(dev_priv, , dev_priv->rps.up_threshold))
+   events |= GEN6_PM_RP_UP_THRESHOLD;
+   else if (!vlv_c0_above(dev_priv, , dev_priv->rps.down_threshold))
+   events |= GEN6_PM_RP_DOWN_THRESHOLD;
 
-   if (pm_iir & GEN6_PM_RP_UP_EI_EXPIRED) {
-   if (vlv_c0_above(dev_priv,
-_priv->rps.up_ei, ,
-dev_priv->rps.up_threshold))
-   events |= GEN6_PM_RP_UP_THRESHOLD;
-   dev_priv->rps.up_ei = now;
-   }
+   dev_priv->rps.ei = now;
 
return events;
 }
@@ -4250,7 +4240,7 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
/* Let's track the enabled rps events */
if (IS_VALLEYVIEW(dev_priv))
/* WaGsvRC0ResidencyMethod:vlv */
-   dev_priv->pm_rps_events = GEN6_PM_RP_DOWN_EI_EXPIRED | 
GEN6_PM_RP_UP_EI_EXPIRED;
+   dev_priv->pm_rps_events = GEN6_PM_RP_UP_EI_EXPIRED;
else
dev_priv->pm_rps_events = GEN6_PM_RPS_EVENTS;
 
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ac0cd82f61e5..56472905d782 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4916,8 +4916,9 @@ static u32 gen6_rps_pm_mask(struct drm_i915_private 
*dev_priv, u8 val)
 {
u32 mask = 0;
 
+   /* We use UP_EI_EXPIRED interupts for both up/down in manual mode */
if (val > dev_priv->rps.min_freq_softlimit)
-   mask |= GEN6_PM_RP_DOWN_EI_EXPIRED | GEN6_PM_RP_DOWN_THRESHOLD 
| GEN6_PM_RP_DOWN_TIMEOUT;
+   mask |= GEN6_PM_RP_UP_EI_EXPIRED | GEN6_PM_RP_DOWN_THRESHOLD | 
GEN6_PM_RP_DOWN_TIMEOUT;
if (val < dev_priv->rps.max_freq_softlimit)
mask |= 

[Intel-gfx] [PATCH 2/2] drm/i915: Defer unmasking RPS interrupts until after making adjustments

[Chris Wilson]

To make our adjustments to RPS requires taking a mutex and potentially
sleeping for an unknown duration - until we have completed our
adjustments further RPS interrupts are immaterial (they are based on
stale thresholds) and we can safely ignore them.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_irq.c | 28 +---
 1 file changed, 13 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 29b10bab38b6..0dfd434584aa 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1120,30 +1120,21 @@ static void gen6_pm_rps_work(struct work_struct *work)
 {
struct drm_i915_private *dev_priv =
container_of(work, struct drm_i915_private, rps.work);
-   bool client_boost;
+   bool client_boost = false;
int new_delay, adj, min, max;
-   u32 pm_iir;
+   u32 pm_iir = 0;
 
spin_lock_irq(_priv->irq_lock);
-   /* Speed up work cancelation during disabling rps interrupts. */
-   if (!dev_priv->rps.interrupts_enabled) {
-   spin_unlock_irq(_priv->irq_lock);
-   return;
+   if (dev_priv->rps.interrupts_enabled) {
+   pm_iir = fetch_and_zero(_priv->rps.pm_iir);
+   client_boost = fetch_and_zero(_priv->rps.client_boost);
}
-
-   pm_iir = dev_priv->rps.pm_iir;
-   dev_priv->rps.pm_iir = 0;
-   /* Make sure not to corrupt PMIMR state used by ringbuffer on GEN6 */
-   gen6_unmask_pm_irq(dev_priv, dev_priv->pm_rps_events);
-   client_boost = dev_priv->rps.client_boost;
-   dev_priv->rps.client_boost = false;
spin_unlock_irq(_priv->irq_lock);
 
/* Make sure we didn't queue anything we're not going to process. */
WARN_ON(pm_iir & ~dev_priv->pm_rps_events);
-
if ((pm_iir & dev_priv->pm_rps_events) == 0 && !client_boost)
-   return;
+   goto out;
 
mutex_lock(_priv->rps.hw_lock);
 
@@ -1200,6 +1191,13 @@ static void gen6_pm_rps_work(struct work_struct *work)
}
 
mutex_unlock(_priv->rps.hw_lock);
+
+out:
+   /* Make sure not to corrupt PMIMR state used by ringbuffer on GEN6 */
+   spin_lock_irq(_priv->irq_lock);
+   if (dev_priv->rps.interrupts_enabled)
+   gen6_unmask_pm_irq(dev_priv, dev_priv->pm_rps_events);
+   spin_unlock_irq(_priv->irq_lock);
 }
 
 
-- 
2.11.0

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

Re: [Intel-gfx] [PATCH v5 4/4] drm/i915: Delay disabling the user interrupt for breadcrumbs

[Chris Wilson]

On Mon, Feb 27, 2017 at 02:06:58PM +, Chris Wilson wrote:
> On Mon, Feb 27, 2017 at 01:57:35PM +, Tvrtko Ursulin wrote:
> > 
> > On 27/02/2017 13:24, Chris Wilson wrote:
> > >   if (b->hangcheck_interrupts != atomic_read(>irq_count)) {
> > >@@ -67,7 +76,7 @@ static void intel_breadcrumbs_hangcheck(unsigned long 
> > >data)
> > >* to process the pending interrupt (e.g, low priority task on a loaded
> > >* system) and wait until it sleeps before declaring a missed interrupt.
> > >*/
> > >-  if (intel_engine_wakeup(engine) & ENGINE_WAKEUP_ACTIVE) {
> > >+  if (!(intel_engine_wakeup(engine) & ENGINE_WAKEUP_ASLEEP)) {
> > 
> > I did not get the explanation from the previous round on why you had
> > to reverse the active to asleep. Here it even looks wrong now,
> > because I thought you don't want to re-queue the hangcheck when
> > there are no waiters?
> 
> No waiters: result = 0
> Running waiter: result = WAKEUP_WAITER
> Sleeping waiter: result = WAKEUP_WAITER | WAKEUP_ASLEEP
> 
> We only want to declare a mised irq if we wake up a sleeping waiter, and
> keep the hangcheck timer running until the device is idle (when the irq
> is disarmed).
> 
> How about:
> 
> if (intel_engine_wakeup(engine) & ENGINE_WAKEUP_ASLEEP) {
>   set_bit(missed_irq);
>   mod_timer(>fake_irq, jiffies + 1);
> } else {
>   mod_timer(b->hangcheck, wait_timeout);
> }

diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index ebb7bc0be9fb..004eb4c0c531 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -72,18 +72,25 @@ static void intel_breadcrumbs_hangcheck(unsigned long data)
return;
}
 
-   /* If the waiter was currently running, assume it hasn't had a chance
+   /* We keep the hangcheck time alive until we disarm the irq, even
+* if there are no waiters at present.
+*
+* If the waiter was currently running, assume it hasn't had a chance
 * to process the pending interrupt (e.g, low priority task on a loaded
 * system) and wait until it sleeps before declaring a missed interrupt.
+*
+* If the waiter was asleep (and not even pending a wakeup), then we
+* must have missed an interrupt as the GPU has stopped advancing
+* but we still have a waiter. Assuming all batches complete within
+* DRM_I915_HANGCHECK_JIFFIES [1.5s]!
 */
-   if (!(intel_engine_wakeup(engine) & ENGINE_WAKEUP_ASLEEP)) {
+   if (intel_engine_wakeup(engine) & ENGINE_WAKEUP_ASLEEP) {
+   DRM_DEBUG("Hangcheck timer elapsed... %s idle\n", engine->name);
+   set_bit(engine->id, >i915->gpu_error.missed_irq_rings);
+   mod_timer(>breadcrumbs.fake_irq, jiffies + 1);
+   } else {
mod_timer(>hangcheck, wait_timeout());
-   return;
}
-
-   DRM_DEBUG("Hangcheck timer elapsed... %s idle\n", engine->name);
-   set_bit(engine->id, >i915->gpu_error.missed_irq_rings);
-   mod_timer(>breadcrumbs.fake_irq, jiffies + 1);
 }
 
 static void intel_breadcrumbs_fake_irq(unsigned long data)
@@ -167,6 +174,10 @@ void intel_engine_disarm_breadcrumbs(struct 
intel_engine_cs *engine)
 
spin_lock_irqsave(>lock, flags);
 
+   /* We only disarm the irq when we are idle (all requests completed),
+* so if there remains a sleeping waiter, it missed the request
+* completion.
+*/
if (__intel_engine_wakeup(engine) & ENGINE_WAKEUP_ASLEEP)
set_bit(engine->id, >i915->gpu_error.missed_irq_rings);



-- 
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 v5 4/4] drm/i915: Delay disabling the user interrupt for breadcrumbs

[Chris Wilson]

On Mon, Feb 27, 2017 at 01:57:35PM +, Tvrtko Ursulin wrote:
> 
> On 27/02/2017 13:24, Chris Wilson wrote:
> > if (b->hangcheck_interrupts != atomic_read(>irq_count)) {
> >@@ -67,7 +76,7 @@ static void intel_breadcrumbs_hangcheck(unsigned long data)
> >  * to process the pending interrupt (e.g, low priority task on a loaded
> >  * system) and wait until it sleeps before declaring a missed interrupt.
> >  */
> >-if (intel_engine_wakeup(engine) & ENGINE_WAKEUP_ACTIVE) {
> >+if (!(intel_engine_wakeup(engine) & ENGINE_WAKEUP_ASLEEP)) {
> 
> I did not get the explanation from the previous round on why you had
> to reverse the active to asleep. Here it even looks wrong now,
> because I thought you don't want to re-queue the hangcheck when
> there are no waiters?

No waiters: result = 0
Running waiter: result = WAKEUP_WAITER
Sleeping waiter: result = WAKEUP_WAITER | WAKEUP_ASLEEP

We only want to declare a mised irq if we wake up a sleeping waiter, and
keep the hangcheck timer running until the device is idle (when the irq
is disarmed).

How about:

if (intel_engine_wakeup(engine) & ENGINE_WAKEUP_ASLEEP) {
set_bit(missed_irq);
mod_timer(>fake_irq, jiffies + 1);
} else {
mod_timer(b->hangcheck, wait_timeout);
}
?
-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: failure for GuC Scrub vol. 1 (rev7)

[Patchwork]

== Series Details ==

Series: GuC Scrub vol. 1 (rev7)
URL   : https://patchwork.freedesktop.org/series/16856/
State : failure

== Summary ==

In file included from drivers/gpu/drm/i915/i915_drv.h:60:0,
 from drivers/gpu/drm/i915/i915_gem_execbuffer.c:37:
drivers/gpu/drm/i915/intel_uc.h:188:1: error: expected identifier or ‘(’ before 
‘<<’ token
 <<< df1dec2d5faca106a651e75b02b845fa246ec77f
 ^
drivers/gpu/drm/i915/intel_uc.h:193:1: error: expected identifier or ‘(’ before 
‘>>’ token
 >>> drm/i915/uc: Introduce intel_uc_init_fw()
 ^
  LD  drivers/pci/pcie/aer/built-in.o
scripts/Makefile.build:294: recipe for target 
'drivers/gpu/drm/i915/intel_device_info.o' failed
make[4]: *** [drivers/gpu/drm/i915/intel_device_info.o] Error 1
scripts/Makefile.build:294: recipe for target 
'drivers/gpu/drm/i915/intel_csr.o' failed
make[4]: *** [drivers/gpu/drm/i915/intel_csr.o] Error 1
  LD  drivers/pci/pcie/built-in.o
scripts/Makefile.build:294: recipe for target 
'drivers/gpu/drm/i915/i915_gem_batch_pool.o' failed
make[4]: *** [drivers/gpu/drm/i915/i915_gem_batch_pool.o] Error 1
scripts/Makefile.build:294: recipe for target 
'drivers/gpu/drm/i915/i915_gem_evict.o' failed
make[4]: *** [drivers/gpu/drm/i915/i915_gem_evict.o] Error 1
scripts/Makefile.build:294: recipe for target 
'drivers/gpu/drm/i915/intel_pipe_crc.o' failed
make[4]: *** [drivers/gpu/drm/i915/intel_pipe_crc.o] Error 1
scripts/Makefile.build:294: recipe for target 
'drivers/gpu/drm/i915/i915_cmd_parser.o' failed
make[4]: *** [drivers/gpu/drm/i915/i915_cmd_parser.o] Error 1
scripts/Makefile.build:294: recipe for target 
'drivers/gpu/drm/i915/i915_debugfs.o' failed
make[4]: *** [drivers/gpu/drm/i915/i915_debugfs.o] Error 1
  LD  drivers/acpi/acpica/built-in.o
scripts/Makefile.build:294: recipe for target 
'drivers/gpu/drm/i915/i915_ioc32.o' failed
make[4]: *** [drivers/gpu/drm/i915/i915_ioc32.o] Error 1
  LD  drivers/acpi/built-in.o
scripts/Makefile.build:294: recipe for target 
'drivers/gpu/drm/i915/i915_gem_clflush.o' failed
make[4]: *** [drivers/gpu/drm/i915/i915_gem_clflush.o] Error 1
scripts/Makefile.build:294: recipe for target 
'drivers/gpu/drm/i915/i915_gem_dmabuf.o' failed
make[4]: *** [drivers/gpu/drm/i915/i915_gem_dmabuf.o] Error 1
  LD  drivers/scsi/scsi_mod.o
  LD  drivers/usb/gadget/udc/udc-core.o
  LD  drivers/usb/gadget/udc/built-in.o
  LD  net/netlink/built-in.o
scripts/Makefile.build:294: recipe for target 
'drivers/gpu/drm/i915/intel_runtime_pm.o' failed
make[4]: *** [drivers/gpu/drm/i915/intel_runtime_pm.o] Error 1
  LD  drivers/usb/gadget/built-in.o
  LD  drivers/video/fbdev/core/fb.o
scripts/Makefile.build:294: recipe for target 
'drivers/gpu/drm/i915/i915_gem_execbuffer.o' failed
make[4]: *** [drivers/gpu/drm/i915/i915_gem_execbuffer.o] Error 1
  LD  drivers/video/fbdev/core/built-in.o
scripts/Makefile.build:294: recipe for target 
'drivers/gpu/drm/i915/i915_gem_context.o' failed
make[4]: *** [drivers/gpu/drm/i915/i915_gem_context.o] Error 1
  LD  drivers/tty/serial/8250/8250_base.o
  LD  drivers/video/fbdev/built-in.o
  LD  drivers/tty/serial/8250/built-in.o
  LD  drivers/tty/serial/built-in.o
scripts/Makefile.build:294: recipe for target 'drivers/gpu/drm/i915/intel_pm.o' 
failed
make[4]: *** [drivers/gpu/drm/i915/intel_pm.o] Error 1
scripts/Makefile.build:553: recipe for target 'drivers/gpu/drm/i915' failed
make[3]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:553: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:553: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
make[1]: *** Waiting for unfinished jobs
  LD  net/unix/unix.o
  AR  lib/lib.a
  LD  drivers/pci/built-in.o
  LD  net/unix/built-in.o
  EXPORTS lib/lib-ksyms.o
  LD  lib/built-in.o
  LD  drivers/usb/core/usbcore.o
  LD  drivers/video/console/built-in.o
  LD  drivers/video/built-in.o
  LD  drivers/usb/core/built-in.o
  LD [M]  drivers/net/ethernet/intel/e1000/e1000.o
  LD  drivers/scsi/sd_mod.o
  LD  drivers/scsi/built-in.o
  LD  net/xfrm/built-in.o
  LD  net/packet/built-in.o
  LD  drivers/tty/vt/built-in.o
  CC  arch/x86/kernel/cpu/capflags.o
  LD  drivers/tty/built-in.o
  LD  arch/x86/kernel/cpu/built-in.o
  LD  fs/btrfs/btrfs.o
  LD  arch/x86/kernel/built-in.o
  LD  fs/btrfs/built-in.o
  LD  net/ipv6/ipv6.o
  LD  arch/x86/built-in.o
  LD  net/ipv6/built-in.o
  LD  drivers/usb/host/xhci-hcd.o
  LD  drivers/md/md-mod.o
  LD  drivers/md/built-in.o
  LD [M]  drivers/net/ethernet/intel/igb/igb.o
  LD  drivers/usb/host/built-in.o
  LD  drivers/usb/built-in.o
  LD  fs/ext4/ext4.o
  LD  fs/ext4/built-in.o
  LD  fs/built-in.o
  LD  net/core/built-in.o
  LD  net/ipv4/built-in.o
  LD [M]  drivers/net/ethernet/intel/e1000e/e1000e.o
  LD  net/built-in.o
  LD  

[Intel-gfx] [CI 3/3] drm/i915: Reduce context alignment

[Chris Wilson]

No hardware was ever shipped that needed more than 4096 byte alignment
and future hardware will not use this legacy path. So reduce the
alignment to make it easier and quicker to launch workloads.

Signed-off-by: Chris Wilson 
Reviewed-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem_context.c | 17 -
 drivers/gpu/drm/i915/i915_gem_context.h |  2 --
 drivers/gpu/drm/i915/intel_ringbuffer.c |  3 ++-
 3 files changed, 2 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 521e6f4705b1..baceca14f5e0 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -92,21 +92,6 @@
 
 #define ALL_L3_SLICES(dev) (1 << NUM_L3_SLICES(dev)) - 1
 
-/* This is a HW constraint. The value below is the largest known requirement
- * I've seen in a spec to date, and that was a workaround for a non-shipping
- * part. It should be safe to decrease this, but it's more future proof as is.
- */
-#define GEN6_CONTEXT_ALIGN (64<<10)
-#define GEN7_CONTEXT_ALIGN I915_GTT_MIN_ALIGNMENT
-
-static size_t get_context_alignment(struct drm_i915_private *dev_priv)
-{
-   if (IS_GEN6(dev_priv))
-   return GEN6_CONTEXT_ALIGN;
-
-   return GEN7_CONTEXT_ALIGN;
-}
-
 static int get_context_size(struct drm_i915_private *dev_priv)
 {
int ret;
@@ -281,8 +266,6 @@ __create_hw_context(struct drm_i915_private *dev_priv,
list_add_tail(>link, _priv->context_list);
ctx->i915 = dev_priv;
 
-   ctx->ggtt_alignment = get_context_alignment(dev_priv);
-
if (dev_priv->hw_context_size) {
struct drm_i915_gem_object *obj;
struct i915_vma *vma;
diff --git a/drivers/gpu/drm/i915/i915_gem_context.h 
b/drivers/gpu/drm/i915/i915_gem_context.h
index 0ac750b90f3d..81268c9770a6 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/i915_gem_context.h
@@ -140,8 +140,6 @@ struct i915_gem_context {
 */
int priority;
 
-   /** ggtt_alignment: alignment restriction for context objects */
-   u32 ggtt_alignment;
/** ggtt_offset_bias: placement restriction for context objects */
u32 ggtt_offset_bias;
 
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index f62afffef682..4a864f8c9387 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1431,7 +1431,8 @@ static int context_pin(struct i915_gem_context *ctx)
return ret;
}
 
-   return i915_vma_pin(vma, 0, ctx->ggtt_alignment, PIN_GLOBAL | PIN_HIGH);
+   return i915_vma_pin(vma, 0, I915_GTT_MIN_ALIGNMENT,
+   PIN_GLOBAL | PIN_HIGH);
 }
 
 static int intel_ring_context_pin(struct intel_engine_cs *engine,
-- 
2.11.0

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

[Intel-gfx] [CI 2/3] drm/i915: Remove redundant TLB invalidate on switching ppgtt

[Chris Wilson]

We are required to reload the TLBs around ppgtt switches. However, we
already do an unconditional TLB invalidate before every batch and a flush
afterwards, so this condition is already satisfied without extra flushes
around the LRI instructions.

Signed-off-by: Chris Wilson 
Reviewed-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 17 -
 1 file changed, 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 875a48b9d05a..e0c9542a90c1 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1464,13 +1464,8 @@ static int hsw_mm_switch(struct i915_hw_ppgtt *ppgtt,
 {
struct intel_engine_cs *engine = req->engine;
u32 *cs;
-   int ret;
 
/* NB: TLBs must be flushed and invalidated before a switch */
-   ret = engine->emit_flush(req, EMIT_INVALIDATE | EMIT_FLUSH);
-   if (ret)
-   return ret;
-
cs = intel_ring_begin(req, 6);
if (IS_ERR(cs))
return PTR_ERR(cs);
@@ -1491,13 +1486,8 @@ static int gen7_mm_switch(struct i915_hw_ppgtt *ppgtt,
 {
struct intel_engine_cs *engine = req->engine;
u32 *cs;
-   int ret;
 
/* NB: TLBs must be flushed and invalidated before a switch */
-   ret = engine->emit_flush(req, EMIT_INVALIDATE | EMIT_FLUSH);
-   if (ret)
-   return ret;
-
cs = intel_ring_begin(req, 6);
if (IS_ERR(cs))
return PTR_ERR(cs);
@@ -1510,13 +1500,6 @@ static int gen7_mm_switch(struct i915_hw_ppgtt *ppgtt,
*cs++ = MI_NOOP;
intel_ring_advance(req, cs);
 
-   /* XXX: RCS is the only one to auto invalidate the TLBs? */
-   if (engine->id != RCS) {
-   ret = engine->emit_flush(req, EMIT_INVALIDATE | EMIT_FLUSH);
-   if (ret)
-   return ret;
-   }
-
return 0;
 }
 
-- 
2.11.0

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

[Intel-gfx] [CI 1/3] drm/i915: Remove redundant TLB invalidate on switching contexts

[Chris Wilson]

We are required to reload the TLBs around context switches
(MI_SET_CONTEXT specifically) and the recommendation is do that before
the MI_SET_CONTEXT so that it is serialised with the switch and not
forgotten:

[DevSNB] If Flush TLB invalidation Mode is enabled it’s the driver’s
responsibility to invalidate the TLBs at least once after the previous
context switch after any GTT mappings changed (including new GTT entries).
This can be done by a pipeline PIPE_CONTROL with TLB inv bit set
immediately before MI_SET_CONTEXT.

However, we already do an unconditional TLB invalidate before every
batch so this condition is satifisfied.

Signed-off-by: Chris Wilson 
Reviewed-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem_context.c | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 99c46f4dbde6..521e6f4705b1 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -607,17 +607,6 @@ mi_set_context(struct drm_i915_gem_request *req, u32 
hw_flags)
0;
int len;
 
-   /* w/a: If Flush TLB Invalidation Mode is enabled, driver must do a TLB
-* invalidation prior to MI_SET_CONTEXT. On GEN6 we don't set the value
-* explicitly, so we rely on the value at ring init, stored in
-* itlb_before_ctx_switch.
-*/
-   if (IS_GEN6(dev_priv)) {
-   int ret = engine->emit_flush(req, EMIT_INVALIDATE);
-   if (ret)
-   return ret;
-   }
-
/* These flags are for resource streamer on HSW+ */
if (IS_HASWELL(dev_priv) || INTEL_GEN(dev_priv) >= 8)
flags |= (HSW_MI_RS_SAVE_STATE_EN | HSW_MI_RS_RESTORE_STATE_EN);
-- 
2.11.0

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

Re: [Intel-gfx] [PATCH v5 4/4] drm/i915: Delay disabling the user interrupt for breadcrumbs

[Tvrtko Ursulin]

On 27/02/2017 13:24, Chris Wilson wrote:

A significant cost in setting up a wait is the overhead of enabling the
interrupt. As we disable the interrupt whenever the queue of waiters is
empty, if we are frequently waiting on alternating batches, we end up
re-enabling the interrupt on a frequent basis. We do want to disable the
interrupt during normal operations as under high load it may add several
thousand interrupts/s - we have been known in the past to occupy whole
cores with our interrupt handler after accidentally leaving user
interrupts enabled. As a compromise, leave the interrupt enabled until
the next IRQ, or the system is idle. This gives a small window for a
waiter to keep the interrupt active and not be delayed by having to
re-enable the interrupt.

v2: Restore hangcheck/missed-irq detection for continuations
v3: Be more careful restoring the hangcheck timer after reset
v4: Be more careful restoring the fake irq after reset (if required!)
v5: Redo changes to intel_engine_wakeup()
v6: Factor out __intel_engine_wakeup()

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem.c  |   4 +-
 drivers/gpu/drm/i915/i915_irq.c  |   2 +
 drivers/gpu/drm/i915/intel_breadcrumbs.c | 148 ---
 drivers/gpu/drm/i915/intel_ringbuffer.h  |   7 +-
 4 files changed, 105 insertions(+), 56 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 01dbba3813c7..0ad080984877 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2988,8 +2988,10 @@ i915_gem_idle_work_handler(struct work_struct *work)
if (wait_for(intel_execlists_idle(dev_priv), 10))
DRM_ERROR("Timeout waiting for engines to idle\n");

-   for_each_engine(engine, dev_priv, id)
+   for_each_engine(engine, dev_priv, id) {
+   intel_engine_disarm_breadcrumbs(engine);
i915_gem_batch_pool_fini(>batch_pool);
+   }

GEM_BUG_ON(!dev_priv->gt.awake);
dev_priv->gt.awake = false;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index bc520ee8d6fe..ca8c7b22748e 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1060,6 +1060,8 @@ static void notify_ring(struct intel_engine_cs *engine)
rq = wait->request;

wake_up_process(wait->tsk);
+   } else {
+   __intel_engine_disarm_breadcrumbs(engine);
}
spin_unlock(>breadcrumbs.lock);

diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index 3855c8c39b35..ebb7bc0be9fb 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -26,19 +26,28 @@

 #include "i915_drv.h"

-unsigned int intel_engine_wakeup(struct intel_engine_cs *engine)
+static unsigned int __intel_engine_wakeup(struct intel_engine_cs *engine)
 {
struct intel_wait *wait;
-   unsigned long flags;
unsigned int result = 0;

-   spin_lock_irqsave(>breadcrumbs.lock, flags);
wait = engine->breadcrumbs.first_wait;
if (wait) {
result = ENGINE_WAKEUP_WAITER;
-   if (!wake_up_process(wait->tsk))
-   result |= ENGINE_WAKEUP_ACTIVE;
+   if (wake_up_process(wait->tsk))
+   result |= ENGINE_WAKEUP_ASLEEP;
}
+
+   return result;
+}
+
+unsigned int intel_engine_wakeup(struct intel_engine_cs *engine)
+{
+   unsigned long flags;
+   unsigned int result = 0;


Can drop the init now.


+
+   spin_lock_irqsave(>breadcrumbs.lock, flags);
+   result = __intel_engine_wakeup(engine);
spin_unlock_irqrestore(>breadcrumbs.lock, flags);

return result;
@@ -54,7 +63,7 @@ static void intel_breadcrumbs_hangcheck(unsigned long data)
struct intel_engine_cs *engine = (struct intel_engine_cs *)data;
struct intel_breadcrumbs *b = >breadcrumbs;

-   if (!b->irq_enabled)
+   if (!b->irq_armed)
return;

if (b->hangcheck_interrupts != atomic_read(>irq_count)) {
@@ -67,7 +76,7 @@ static void intel_breadcrumbs_hangcheck(unsigned long data)
 * to process the pending interrupt (e.g, low priority task on a loaded
 * system) and wait until it sleeps before declaring a missed interrupt.
 */
-   if (intel_engine_wakeup(engine) & ENGINE_WAKEUP_ACTIVE) {
+   if (!(intel_engine_wakeup(engine) & ENGINE_WAKEUP_ASLEEP)) {


I did not get the explanation from the previous round on why you had to 
reverse the active to asleep. Here it even looks wrong now, because I 
thought you don't want to re-queue the hangcheck when there are no waiters?



mod_timer(>hangcheck, wait_timeout());
return;
}

Re: [Intel-gfx] [PATCH v2] Add the new tool for create GVT-g Linux guest based on KVMGT

[Petri Latvala]

On 02/27/2017 10:13 AM, Xu, Terrence wrote:

[Xu, Terrence] Yes the root is needed for all our "echo" related commands, can I suppose 
the case is running under root privilege? Or need to return "skip" when it is not under 
root privilege?



Right, seems I was a bit confused there and there are other cases where 
root rights are required.


Assuming root privileges is fine, especially if you're nice and warn the 
user if proper rights are not active. Can the tool be used as a normal 
user at all?



--
Petri Latvala

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

Re: [Intel-gfx] [PATCH] ACPI / bus: Introduce a list of ids for "always present" devices

[Rafael J. Wysocki]

+Mika & Andy

On Saturday, February 25, 2017 07:23:28 PM Hans de Goede wrote:
> Several cherrytrail devices (all of which ship with windows 10) hide the
> lpss pwm controller in ACPI, typically the _STA method looks like this:
> 
> Method (_STA, 0, NotSerialized)  // _STA: Status
> {
> If (OSID == One)
> {
> Return (Zero)
> }
> 
> Return (0x0F)
> }
> 
> Where OSID is some dark magic seen in all cherrytrail ACPI tables making
> the machine behave differently depending on which OS it *thinks* it is
> booting, this gets set in a number of ways which we cannot control, on
> some newer machines it simple hardcoded to "One" aka win10.
> 
> This causes the PWM controller to get hidden, which means Linux cannot
> control the backlight level on cht based tablets / laptops.
> 
> Since loading the driver for this does no harm (the only in kernel user
> of it is the i915 driver, which will only use it when it needs it), this
> commit makes acpi_bus_get_status() always set status to ACPI_STA_DEFAULT
> for the 80862288 device, fixing the lack of backlight control.
> 
> Signed-off-by: Hans de Goede 
> ---
>  drivers/acpi/bus.c | 25 +
>  1 file changed, 25 insertions(+)
> 
> diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
> index 95855cb..483d4d0 100644
> --- a/drivers/acpi/bus.c
> +++ b/drivers/acpi/bus.c
> @@ -109,11 +109,36 @@ acpi_status acpi_bus_get_status_handle(acpi_handle 
> handle,
>   return status;
>  }
>  
> +/*
> + * Some ACPI devices are hidden (status == 0x0) in recent BIOS-es because
> + * some recent windows drivers bind to one device but poke at multiple
> + * devices at the same time, so the others get hidden.
> + * We work around this by always reporting ACPI_STA_DEFAULT for these
> + * devices. Note this MUST only be done for devices where this is safe.
> + */
> +static const struct acpi_device_id always_present_device_ids[] = {
> + /*
> +  * Cherrytrail pwm directly poked by GPU driver in win10,
> +  * but Linux uses a separate pwm driver, harmless if not used.
> +  */
> + { "80862288", },
> + { }
> +};
> +
>  int acpi_bus_get_status(struct acpi_device *device)
>  {
>   acpi_status status;
>   unsigned long long sta;
>  
> + /* acpi_match_device_ids checks status, so start with default */
> + acpi_set_device_status(device, ACPI_STA_DEFAULT);

This shouldn't be done in a "get" routine.

Ideally, a scan handler should do that or similar.

> + if (acpi_match_device_ids(device, always_present_device_ids) == 0) {
> + ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Device [%s] is in always 
> present list setting status [%08x]\n",
> +   device->pnp.bus_id, ACPI_STA_DEFAULT));

pr_debug() please.  The ACPI_DEBUG_PRINT() stuff is basically for ACPICA
(yes, I know it is used elsewhere and no, it is not a good idea to do that).

> + return 0;
> + }
> + acpi_set_device_status(device, 0);
> +
>   status = acpi_bus_get_status_handle(device->handle, );
>   if (ACPI_FAILURE(status))
>   return -ENODEV;
> 

Thanks,
Rafael

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

[Intel-gfx] [PATCH 1/3] drm/i915: Start splitting out i915_gem_object routines

[Chris Wilson]

To begin with move obj->mm related operations to i915_gem_object.c, in
preparation for future tweaks.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/Makefile  |   1 +
 drivers/gpu/drm/i915/i915_drv.h| 107 --
 drivers/gpu/drm/i915/i915_gem.c| 385 +--
 drivers/gpu/drm/i915/i915_gem_object.c | 412 +
 drivers/gpu/drm/i915/i915_gem_object.h | 112 +-
 .../selftests/{i915_gem_object.c => i915_gem.c}|   4 +-
 .../gpu/drm/i915/selftests/i915_live_selftests.h   |   2 +-
 .../gpu/drm/i915/selftests/i915_mock_selftests.h   |   2 +-
 8 files changed, 529 insertions(+), 496 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_gem_object.c
 rename drivers/gpu/drm/i915/selftests/{i915_gem_object.c => i915_gem.c} (99%)

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index d1d8ec49791c..1dbbcd3e23b1 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -40,6 +40,7 @@ i915-y += i915_cmd_parser.o \
  i915_gem_gtt.o \
  i915_gem_internal.o \
  i915_gem.o \
+ i915_gem_object.o \
  i915_gem_render_state.o \
  i915_gem_request.o \
  i915_gem_shrinker.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3d76f9d16cc2..b88c6c58a860 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3285,113 +3285,6 @@ static inline int __sg_page_count(const struct 
scatterlist *sg)
return sg->length >> PAGE_SHIFT;
 }
 
-struct scatterlist *
-i915_gem_object_get_sg(struct drm_i915_gem_object *obj,
-  unsigned int n, unsigned int *offset);
-
-struct page *
-i915_gem_object_get_page(struct drm_i915_gem_object *obj,
-unsigned int n);
-
-struct page *
-i915_gem_object_get_dirty_page(struct drm_i915_gem_object *obj,
-  unsigned int n);
-
-dma_addr_t
-i915_gem_object_get_dma_address(struct drm_i915_gem_object *obj,
-   unsigned long n);
-
-void __i915_gem_object_set_pages(struct drm_i915_gem_object *obj,
-struct sg_table *pages);
-int __i915_gem_object_get_pages(struct drm_i915_gem_object *obj);
-
-static inline int __must_check
-i915_gem_object_pin_pages(struct drm_i915_gem_object *obj)
-{
-   might_lock(>mm.lock);
-
-   if (atomic_inc_not_zero(>mm.pages_pin_count))
-   return 0;
-
-   return __i915_gem_object_get_pages(obj);
-}
-
-static inline void
-__i915_gem_object_pin_pages(struct drm_i915_gem_object *obj)
-{
-   GEM_BUG_ON(!obj->mm.pages);
-
-   atomic_inc(>mm.pages_pin_count);
-}
-
-static inline bool
-i915_gem_object_has_pinned_pages(struct drm_i915_gem_object *obj)
-{
-   return atomic_read(>mm.pages_pin_count);
-}
-
-static inline void
-__i915_gem_object_unpin_pages(struct drm_i915_gem_object *obj)
-{
-   GEM_BUG_ON(!i915_gem_object_has_pinned_pages(obj));
-   GEM_BUG_ON(!obj->mm.pages);
-
-   atomic_dec(>mm.pages_pin_count);
-}
-
-static inline void
-i915_gem_object_unpin_pages(struct drm_i915_gem_object *obj)
-{
-   __i915_gem_object_unpin_pages(obj);
-}
-
-enum i915_mm_subclass { /* lockdep subclass for obj->mm.lock */
-   I915_MM_NORMAL = 0,
-   I915_MM_SHRINKER
-};
-
-void __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
-enum i915_mm_subclass subclass);
-void __i915_gem_object_invalidate(struct drm_i915_gem_object *obj);
-
-enum i915_map_type {
-   I915_MAP_WB = 0,
-   I915_MAP_WC,
-};
-
-/**
- * i915_gem_object_pin_map - return a contiguous mapping of the entire object
- * @obj: the object to map into kernel address space
- * @type: the type of mapping, used to select pgprot_t
- *
- * Calls i915_gem_object_pin_pages() to prevent reaping of the object's
- * pages and then returns a contiguous mapping of the backing storage into
- * the kernel address space. Based on the @type of mapping, the PTE will be
- * set to either WriteBack or WriteCombine (via pgprot_t).
- *
- * The caller is responsible for calling i915_gem_object_unpin_map() when the
- * mapping is no longer required.
- *
- * Returns the pointer through which to access the mapped object, or an
- * ERR_PTR() on error.
- */
-void *__must_check i915_gem_object_pin_map(struct drm_i915_gem_object *obj,
-  enum i915_map_type type);
-
-/**
- * i915_gem_object_unpin_map - releases an earlier mapping
- * @obj: the object to unmap
- *
- * After pinning the object and mapping its pages, once you are finished
- * with your access, call i915_gem_object_unpin_map() to release the pin
- * upon the mapping. Once the pin count reaches zero, that mapping may be
- * removed.
- */
-static inline void i915_gem_object_unpin_map(struct drm_i915_gem_object *obj)
-{

[Intel-gfx] [PATCH 2/3] drm/i915: Exercise backing storage of mock gem objects

[Chris Wilson]

Check that we can retrieve the right page for a random index, and that
we can map the whole object.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem_object.c |   1 +
 drivers/gpu/drm/i915/selftests/i915_gem_object.c   | 405 +
 .../gpu/drm/i915/selftests/i915_mock_selftests.h   |   1 +
 3 files changed, 407 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/selftests/i915_gem_object.c

diff --git a/drivers/gpu/drm/i915/i915_gem_object.c 
b/drivers/gpu/drm/i915/i915_gem_object.c
index f222980cee34..30a704ea7e3b 100644
--- a/drivers/gpu/drm/i915/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/i915_gem_object.c
@@ -409,4 +409,5 @@ void *i915_gem_object_pin_map(struct drm_i915_gem_object 
*obj,
 
 #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
 #include "selftests/huge_gem_object.c"
+#include "selftests/i915_gem_object.c"
 #endif
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_object.c 
b/drivers/gpu/drm/i915/selftests/i915_gem_object.c
new file mode 100644
index ..1328332150f6
--- /dev/null
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_object.c
@@ -0,0 +1,405 @@
+/*
+ * Copyright © 2017 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 "../i915_selftest.h"
+#include "i915_random.h"
+
+#include "mock_gem_device.h"
+
+#define PFN_BIAS 0x1000
+
+static void fake_free_pages(struct drm_i915_gem_object *obj,
+   struct sg_table *pages)
+{
+   sg_free_table(pages);
+   kfree(pages);
+}
+
+static struct sg_table *
+fake_get_pages(struct drm_i915_gem_object *obj)
+{
+#define GFP (GFP_KERNEL | __GFP_NOWARN | __GFP_NORETRY)
+   struct sg_table *pages;
+   struct scatterlist *sg;
+   struct rnd_state prng;
+   unsigned long pfn, rem;
+
+   prandom_seed_state(, obj->scratch);
+
+   pages = kmalloc(sizeof(*pages), GFP);
+   if (!pages)
+   return ERR_PTR(-ENOMEM);
+
+   rem = obj->base.size >> PAGE_SHIFT;
+   if (sg_alloc_table(pages, obj->base.size >> PAGE_SHIFT, GFP)) {
+   kfree(pages);
+   return ERR_PTR(-ENOMEM);
+   }
+
+   pfn = PFN_BIAS;
+   for (sg = pages->sgl; sg; sg = sg_next(sg)) {
+   unsigned int len = 1 + prandom_u32_state() % rem;
+
+   sg_set_page(sg, pfn_to_page(pfn), len * PAGE_SIZE, 0);
+
+   pfn += len;
+   rem -= len;
+   if (!rem) {
+   sg_mark_end(sg);
+   break;
+   }
+   }
+   GEM_BUG_ON(rem);
+
+   obj->mm.madv = I915_MADV_DONTNEED;
+   return pages;
+#undef GFP
+}
+
+static void fake_put_pages(struct drm_i915_gem_object *obj,
+  struct sg_table *pages)
+{
+   fake_free_pages(obj, pages);
+   obj->mm.dirty = false;
+   obj->mm.madv = I915_MADV_WILLNEED;
+}
+
+static const struct drm_i915_gem_object_ops fake_ops = {
+   .flags = I915_GEM_OBJECT_HAS_STRUCT_PAGE,
+   .get_pages = fake_get_pages,
+   .put_pages = fake_put_pages,
+};
+
+static struct drm_i915_gem_object *
+fake_object(struct drm_i915_private *i915, u64 size, u32 seed)
+{
+   struct drm_i915_gem_object *obj;
+
+   GEM_BUG_ON(!size);
+   GEM_BUG_ON(!IS_ALIGNED(size, PAGE_SIZE));
+
+   if (overflows_type(size, obj->base.size))
+   return ERR_PTR(-E2BIG);
+
+   obj = i915_gem_object_alloc(i915);
+   if (!obj)
+   return ERR_PTR(-ENOMEM);
+
+   drm_gem_private_object_init(>drm, >base, size);
+   i915_gem_object_init(obj, _ops);
+
+   obj->base.write_domain = I915_GEM_DOMAIN_CPU;
+   obj->base.read_domains = I915_GEM_DOMAIN_CPU;
+   obj->cache_level = I915_CACHE_NONE;
+
+   obj->scratch = seed;
+
+   return obj;
+}
+
+static unsigned int *order_forward(unsigned int count, struct rnd_state *prng)
+{

[Intel-gfx] [PATCH 3/3] drm/i915: Prepare for async get_pages

[Chris Wilson]

In the next patch, we will allow for obj->mm.__pages to be populated
asynchronously. This means that simply acquiring a pages_pin_count is no
longer sufficient to be sure the pages are there, we need to acquire the
pin (to prevent the pages from disappearing again) and then wait for the
completion.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem.c  | 26 +++---
 drivers/gpu/drm/i915/i915_gem_clflush.c  |  4 +-
 drivers/gpu/drm/i915/i915_gem_dmabuf.c   | 14 --
 drivers/gpu/drm/i915/i915_gem_gtt.c  | 23 +++--
 drivers/gpu/drm/i915/i915_gem_object.c   | 61 
 drivers/gpu/drm/i915/i915_gem_object.h   | 47 ++
 drivers/gpu/drm/i915/i915_gem_render_state.c |  2 +-
 drivers/gpu/drm/i915/i915_gem_shrinker.c | 14 +++---
 drivers/gpu/drm/i915/i915_gem_stolen.c   |  2 +-
 drivers/gpu/drm/i915/i915_gem_tiling.c   |  2 +-
 drivers/gpu/drm/i915/i915_gem_userptr.c  | 48 +--
 drivers/gpu/drm/i915/i915_vma.c  |  4 +-
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c|  4 +-
 drivers/gpu/drm/i915/selftests/i915_gem_object.c | 45 +++--
 drivers/gpu/drm/i915/selftests/i915_vma.c|  6 +--
 drivers/gpu/drm/i915/selftests/mock_gtt.c|  2 +-
 16 files changed, 203 insertions(+), 101 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0316215221f8..ce3d83f924bf 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -596,7 +596,7 @@ i915_gem_object_attach_phys(struct drm_i915_gem_object *obj,
return ret;
 
__i915_gem_object_put_pages(obj, I915_MM_NORMAL);
-   if (obj->mm.pages)
+   if (i915_gem_object_has_pages(obj))
return -EBUSY;
 
GEM_BUG_ON(obj->ops != _gem_object_ops);
@@ -2144,7 +2144,7 @@ void __i915_gem_object_invalidate(struct 
drm_i915_gem_object *obj)
struct address_space *mapping;
 
lockdep_assert_held(>mm.lock);
-   GEM_BUG_ON(obj->mm.pages);
+   GEM_BUG_ON(i915_gem_object_has_pages(obj));
 
switch (obj->mm.madv) {
case I915_MADV_DONTNEED:
@@ -3867,7 +3867,7 @@ i915_gem_madvise_ioctl(struct drm_device *dev, void *data,
if (err)
goto out;
 
-   if (obj->mm.pages &&
+   if (i915_gem_object_has_pages(obj) &&
i915_gem_object_is_tiled(obj) &&
dev_priv->quirks & QUIRK_PIN_SWIZZLED_PAGES) {
if (obj->mm.madv == I915_MADV_WILLNEED) {
@@ -3886,7 +3886,8 @@ i915_gem_madvise_ioctl(struct drm_device *dev, void *data,
obj->mm.madv = args->madv;
 
/* if the object is no longer attached, discard its backing storage */
-   if (obj->mm.madv == I915_MADV_DONTNEED && !obj->mm.pages)
+   if (obj->mm.madv == I915_MADV_DONTNEED &&
+   !i915_gem_object_has_pages(obj))
i915_gem_object_truncate(obj);
 
args->retained = obj->mm.madv != __I915_MADV_PURGED;
@@ -3928,6 +3929,8 @@ void i915_gem_object_init(struct drm_i915_gem_object *obj,
obj->mm.madv = I915_MADV_WILLNEED;
INIT_RADIX_TREE(>mm.get_page.radix, GFP_KERNEL | __GFP_NOWARN);
mutex_init(>mm.get_page.lock);
+   init_completion(>mm.complete);
+   complete_all(>mm.complete);
 
i915_gem_info_add_obj(to_i915(obj->base.dev), obj->base.size);
 }
@@ -4071,7 +4074,7 @@ static void __i915_gem_free_objects(struct 
drm_i915_private *i915,
if (WARN_ON(i915_gem_object_has_pinned_pages(obj)))
atomic_set(>mm.pages_pin_count, 0);
__i915_gem_object_put_pages(obj, I915_MM_NORMAL);
-   GEM_BUG_ON(obj->mm.pages);
+   GEM_BUG_ON(i915_gem_object_has_pages(obj));
 
if (obj->base.import_attach)
drm_prime_gem_destroy(>base, NULL);
@@ -4772,7 +4775,16 @@ i915_gem_object_create_from_data(struct drm_i915_private 
*dev_priv,
if (ret)
goto fail;
 
-   sg = obj->mm.pages;
+   ret = i915_gem_object_wait_for_pages(obj);
+   if (ret)
+   goto fail_unpin;
+
+   sg = i915_gem_object_pages(obj);
+   if (IS_ERR(sg)) {
+   ret = PTR_ERR(sg);
+   goto fail_unpin;
+   }
+
bytes = sg_copy_from_buffer(sg->sgl, sg->nents, (void *)data, size);
obj->mm.dirty = true; /* Backing store is now out of date */
i915_gem_object_unpin_pages(obj);
@@ -4785,6 +4797,8 @@ i915_gem_object_create_from_data(struct drm_i915_private 
*dev_priv,
 
return obj;
 
+fail_unpin:
+   i915_gem_object_unpin_pages(obj);
 fail:
i915_gem_object_put(obj);
return ERR_PTR(ret);
diff --git a/drivers/gpu/drm/i915/i915_gem_clflush.c 
b/drivers/gpu/drm/i915/i915_gem_clflush.c
index d925fb582ba7..d68817231e98 100644
--- 

[Intel-gfx] Start planning for handling async pages, binding, everything

[Chris Wilson]

Currently we have a heavyweight EAGAIN loop round tripping to userspace
to handle asynchronous loading. However, we now have fences to handle
asynchronous execution. Fun times ahead. For starters, let's move the
current asynchronous get_pages onto a more secure footing.
-Chris

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

Re: [Intel-gfx] [PATCH 10/10] drm/i915/uc: Add params for specifying firmware

[Jani Nikula]

On Mon, 27 Feb 2017, Joonas Lahtinen  wrote:
> On pe, 2017-02-24 at 16:40 +0100, Arkadiusz Hiler wrote:
>> `guc_firmware_path` and `huc_firmware_path` module parameters are added.
>> 
>> Using the parameter disabled version checks and loads desired firmware
>> instead of the default one.
>> 
>> Cc: Chris Wilson 
>> Cc: Joonas Lahtinen 
>> Cc: Michal Winiarski 
>> Signed-off-by: Arkadiusz Hiler 
>
> 
>
>> @@ -230,6 +232,14 @@ module_param_named(guc_log_level, i915.guc_log_level, 
>> int, 0400);
>>  MODULE_PARM_DESC(guc_log_level,
>>  "GuC firmware logging level (-1:disabled (default), 0-3:enabled)");
>>  
>> +module_param_named(guc_firmware_path, i915.guc_firmware_path, charp, 0400);
>
> I'm pretty sure this should be _unsafe, because it overrides the
> version checks. Cc'd Jani for this.

Yes, please. I replied the same thing to Chris' patches adding the same
thing.

BR,
Jani.

>
>> @@ -479,7 +479,11 @@ void intel_guc_select_fw(struct intel_guc *guc)
>>  guc->fw.load_status = INTEL_UC_FIRMWARE_NONE;
>>  guc->fw.fw = INTEL_UC_FW_TYPE_GUC;
>>  
>> -if (IS_SKYLAKE(dev_priv)) {
>> +if (i915.guc_firmware_path) {
>> +guc->fw.path = i915.guc_firmware_path;
>> +guc->fw.major_ver_wanted = 0;
>> +guc->fw.minor_ver_wanted = 0;
>
> Or, we could keep the wanted version number, only replace the path, and
> spit out WARN/taint kernel if some other version was detected?
>
> But I guess the main purpose is to override version (not provide
> request_firmware workarounds), so my vote is to make the param _unsafe.
>
> Regards, Joonas

-- 
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] I915 dmesg warnings on Mac Mini, solo core edition

[Jani Nikula]

On Sun, 26 Feb 2017, Enrico Mioso  wrote:
> Hello. I am not using this computer actively and can't report easily
> on the state of the screen.  Still, I observed the following situation
> in the system's dmesg: running the stock Archlinux Kernel.  This is an
> Apple MacMini system, booted via an EFI bootloader.

Please file a bug over at [1], add drm.debug=14 module parameter and
attach the dmesg with that on the bug. Please also try v4.10 kernel or
drm-tip branch of https://cgit.freedesktop.org/drm-tip.

BR,
Jani.

[1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI=DRM/Intel


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

[Intel-gfx] [PATCH v5 2/4] drm/i915: Signal first fence from irq handler if complete

[Chris Wilson]

As execlists and other non-semaphore multi-engine devices coordinate
between engines using interrupts, we can shave off a few 10s of
microsecond of scheduling latency by doing the fence signaling from the
interrupt as opposed to a RT kthread. (Realistically the delay adds
about 1% to an individual cross-engine workload.) We only signal the
first fence in order to limit the amount of work we move into the
interrupt handler. We also have to remember that our breadcrumbs may be
unordered with respect to the interrupt and so we still require the
waiter process to perform some heavyweight coherency fixups, as well as
traversing the tree of waiters.

v2: No need for early exit in irq handler - it breaks the flow between
patches and prevents the tracepoint
v3: Restore rcu hold across irq signaling of request

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.h  | 13 ++--
 drivers/gpu/drm/i915/i915_gem_request.c  |  2 +-
 drivers/gpu/drm/i915/i915_gem_request.h  |  2 ++
 drivers/gpu/drm/i915/i915_irq.c  | 36 +---
 drivers/gpu/drm/i915/intel_breadcrumbs.c | 32 +++-
 drivers/gpu/drm/i915/intel_ringbuffer.h  |  8 +++
 6 files changed, 54 insertions(+), 39 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9c5b3dd9f6f1..ca2c986a48cf 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -4073,9 +4073,9 @@ __i915_request_irq_complete(const struct 
drm_i915_gem_request *req)
 * is woken.
 */
if (engine->irq_seqno_barrier &&
-   rcu_access_pointer(engine->breadcrumbs.irq_seqno_bh) == current &&
test_and_clear_bit(ENGINE_IRQ_BREADCRUMB, >irq_posted)) {
-   struct task_struct *tsk;
+   struct intel_breadcrumbs *b = >breadcrumbs;
+   unsigned long flags;
 
/* The ordering of irq_posted versus applying the barrier
 * is crucial. The clearing of the current irq_posted must
@@ -4097,17 +4097,16 @@ __i915_request_irq_complete(const struct 
drm_i915_gem_request *req)
 * the seqno before we believe it coherent since they see
 * irq_posted == false but we are still running).
 */
-   rcu_read_lock();
-   tsk = rcu_dereference(engine->breadcrumbs.irq_seqno_bh);
-   if (tsk && tsk != current)
+   spin_lock_irqsave(>lock, flags);
+   if (b->first_wait && b->first_wait->tsk != current)
/* Note that if the bottom-half is changed as we
 * are sending the wake-up, the new bottom-half will
 * be woken by whomever made the change. We only have
 * to worry about when we steal the irq-posted for
 * ourself.
 */
-   wake_up_process(tsk);
-   rcu_read_unlock();
+   wake_up_process(b->first_wait->tsk);
+   spin_unlock_irqrestore(>lock, flags);
 
if (__i915_gem_request_completed(req, seqno))
return true;
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index fbfeb5f8d069..77c3ee7a3fd0 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -1083,7 +1083,7 @@ long i915_wait_request(struct drm_i915_gem_request *req,
if (flags & I915_WAIT_LOCKED)
add_wait_queue(errq, );
 
-   intel_wait_init();
+   intel_wait_init(, req);
 
 restart:
do {
diff --git a/drivers/gpu/drm/i915/i915_gem_request.h 
b/drivers/gpu/drm/i915/i915_gem_request.h
index 5f73d8c0a38a..0efee879df23 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.h
+++ b/drivers/gpu/drm/i915/i915_gem_request.h
@@ -32,10 +32,12 @@
 
 struct drm_file;
 struct drm_i915_gem_object;
+struct drm_i915_gem_request;
 
 struct intel_wait {
struct rb_node node;
struct task_struct *tsk;
+   struct drm_i915_gem_request *request;
u32 seqno;
 };
 
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index bc70e2c451b2..bc520ee8d6fe 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1033,12 +1033,42 @@ static void ironlake_rps_change_irq_handler(struct 
drm_i915_private *dev_priv)
 
 static void notify_ring(struct intel_engine_cs *engine)
 {
-   bool waiters;
+   struct drm_i915_gem_request *rq = NULL;
+   struct intel_wait *wait;
 
atomic_inc(>irq_count);
set_bit(ENGINE_IRQ_BREADCRUMB, >irq_posted);
-   waiters = intel_engine_wakeup(engine);
-   

[Intel-gfx] [PATCH v5 1/4] drm/i915: Report both waiters and success from intel_engine_wakeup()

[Chris Wilson]

The two users of the return value from intel_engine_wakeup() are
expecting different results. In the breadcrumbs hangcheck, we are using
it to determine whether wake_up_process() detected the waiter was
currently running (and if so we presume that it hasn't yet missed the
interrupt). However, in the fake_irq path, we are using the return value
as a check as to whether there are any waiters, and so we may
incorrectly stop the fake-irq if that waiter was currently running.

To handle the two different needs, return both bits of information! We
uninline it from the irq path in preparation for the next patch which
makes the irq hotpath special and relegates intel_engine_wakeup() to the
slow fixup paths.

v2: s/ret/result/

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_breadcrumbs.c | 28 +++-
 drivers/gpu/drm/i915/intel_ringbuffer.h  | 26 +++---
 2 files changed, 30 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index 027c93e34c97..c8361f350350 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -26,6 +26,32 @@
 
 #include "i915_drv.h"
 
+unsigned int intel_engine_wakeup(struct intel_engine_cs *engine)
+{
+   unsigned int result = 0;
+
+   /* Note that for this not to dangerously chase a dangling pointer,
+* we must hold the rcu_read_lock here.
+*
+* Also note that tsk is likely to be in !TASK_RUNNING state so an
+* early test for tsk->state != TASK_RUNNING before wake_up_process()
+* is unlikely to be beneficial.
+*/
+   if (intel_engine_has_waiter(engine)) {
+   struct task_struct *tsk;
+
+   result = ENGINE_WAKEUP_WAITER;
+
+   rcu_read_lock();
+   tsk = rcu_dereference(engine->breadcrumbs.irq_seqno_bh);
+   if (tsk && !wake_up_process(tsk))
+   result |= ENGINE_WAKEUP_ACTIVE;
+   rcu_read_unlock();
+   }
+
+   return result;
+}
+
 static unsigned long wait_timeout(void)
 {
return round_jiffies_up(jiffies + DRM_I915_HANGCHECK_JIFFIES);
@@ -49,7 +75,7 @@ static void intel_breadcrumbs_hangcheck(unsigned long data)
 * to process the pending interrupt (e.g, low priority task on a loaded
 * system) and wait until it sleeps before declaring a missed interrupt.
 */
-   if (!intel_engine_wakeup(engine)) {
+   if (intel_engine_wakeup(engine) & ENGINE_WAKEUP_ACTIVE) {
mod_timer(>hangcheck, wait_timeout());
return;
}
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 0f29e07a9581..7d753dc1b89d 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -642,29 +642,9 @@ static inline bool intel_engine_has_waiter(const struct 
intel_engine_cs *engine)
return rcu_access_pointer(engine->breadcrumbs.irq_seqno_bh);
 }
 
-static inline bool intel_engine_wakeup(const struct intel_engine_cs *engine)
-{
-   bool wakeup = false;
-
-   /* Note that for this not to dangerously chase a dangling pointer,
-* we must hold the rcu_read_lock here.
-*
-* Also note that tsk is likely to be in !TASK_RUNNING state so an
-* early test for tsk->state != TASK_RUNNING before wake_up_process()
-* is unlikely to be beneficial.
-*/
-   if (intel_engine_has_waiter(engine)) {
-   struct task_struct *tsk;
-
-   rcu_read_lock();
-   tsk = rcu_dereference(engine->breadcrumbs.irq_seqno_bh);
-   if (tsk)
-   wakeup = wake_up_process(tsk);
-   rcu_read_unlock();
-   }
-
-   return wakeup;
-}
+unsigned int intel_engine_wakeup(struct intel_engine_cs *engine);
+#define ENGINE_WAKEUP_WAITER BIT(0)
+#define ENGINE_WAKEUP_ACTIVE BIT(1)
 
 void intel_engine_reset_breadcrumbs(struct intel_engine_cs *engine);
 void intel_engine_fini_breadcrumbs(struct intel_engine_cs *engine);
-- 
2.11.0

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

[Intel-gfx] [PATCH v5 3/4] drm/i915: Defer enabling hangcheck to the first fake breadcrumb interrupt

[Chris Wilson]

By deferring hangcheck to the fake breadcrumb interrupt, we can simply
the enabling procedure slightly - as by enabling the fake, we then
enable the hangcheck. By always enabling the hangcheck from each fake
interrupt (it will be a no-op for an already queued hangcheck), it will
make restoring the breadcrumbs after a reset simpler in the next patch.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_breadcrumbs.c | 36 
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index e7f4a4c923a2..3855c8c39b35 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -75,17 +75,6 @@ static void intel_breadcrumbs_hangcheck(unsigned long data)
DRM_DEBUG("Hangcheck timer elapsed... %s idle\n", engine->name);
set_bit(engine->id, >i915->gpu_error.missed_irq_rings);
mod_timer(>breadcrumbs.fake_irq, jiffies + 1);
-
-   /* Ensure that even if the GPU hangs, we get woken up.
-*
-* However, note that if no one is waiting, we never notice
-* a gpu hang. Eventually, we will have to wait for a resource
-* held by the GPU and so trigger a hangcheck. In the most
-* pathological case, this will be upon memory starvation! To
-* prevent this, we also queue the hangcheck from the retire
-* worker.
-*/
-   i915_queue_hangcheck(engine->i915);
 }
 
 static void intel_breadcrumbs_fake_irq(unsigned long data)
@@ -99,8 +88,21 @@ static void intel_breadcrumbs_fake_irq(unsigned long data)
 * every jiffie in order to kick the oldest waiter to do the
 * coherent seqno check.
 */
-   if (intel_engine_wakeup(engine))
-   mod_timer(>breadcrumbs.fake_irq, jiffies + 1);
+   if (!intel_engine_wakeup(engine))
+   return;
+
+   mod_timer(>breadcrumbs.fake_irq, jiffies + 1);
+
+   /* Ensure that even if the GPU hangs, we get woken up.
+*
+* However, note that if no one is waiting, we never notice
+* a gpu hang. Eventually, we will have to wait for a resource
+* held by the GPU and so trigger a hangcheck. In the most
+* pathological case, this will be upon memory starvation! To
+* prevent this, we also queue the hangcheck from the retire
+* worker.
+*/
+   i915_queue_hangcheck(engine->i915);
 }
 
 static void irq_enable(struct intel_engine_cs *engine)
@@ -179,13 +181,11 @@ static void __intel_breadcrumbs_enable_irq(struct 
intel_breadcrumbs *b)
b->irq_enabled = true;
}
 
-   if (!b->irq_enabled || use_fake_irq(b)) {
+   /* Ensure we never sleep indefinitely */
+   if (!b->irq_enabled || use_fake_irq(b))
mod_timer(>fake_irq, jiffies + 1);
-   i915_queue_hangcheck(i915);
-   } else {
-   /* Ensure we never sleep indefinitely */
+   else
mod_timer(>hangcheck, wait_timeout());
-   }
 }
 
 static void __intel_breadcrumbs_disable_irq(struct intel_breadcrumbs *b)
-- 
2.11.0

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

[Intel-gfx] [PATCH v5 4/4] drm/i915: Delay disabling the user interrupt for breadcrumbs

[Chris Wilson]

A significant cost in setting up a wait is the overhead of enabling the
interrupt. As we disable the interrupt whenever the queue of waiters is
empty, if we are frequently waiting on alternating batches, we end up
re-enabling the interrupt on a frequent basis. We do want to disable the
interrupt during normal operations as under high load it may add several
thousand interrupts/s - we have been known in the past to occupy whole
cores with our interrupt handler after accidentally leaving user
interrupts enabled. As a compromise, leave the interrupt enabled until
the next IRQ, or the system is idle. This gives a small window for a
waiter to keep the interrupt active and not be delayed by having to
re-enable the interrupt.

v2: Restore hangcheck/missed-irq detection for continuations
v3: Be more careful restoring the hangcheck timer after reset
v4: Be more careful restoring the fake irq after reset (if required!)
v5: Redo changes to intel_engine_wakeup()
v6: Factor out __intel_engine_wakeup()

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem.c  |   4 +-
 drivers/gpu/drm/i915/i915_irq.c  |   2 +
 drivers/gpu/drm/i915/intel_breadcrumbs.c | 148 ---
 drivers/gpu/drm/i915/intel_ringbuffer.h  |   7 +-
 4 files changed, 105 insertions(+), 56 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 01dbba3813c7..0ad080984877 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2988,8 +2988,10 @@ i915_gem_idle_work_handler(struct work_struct *work)
if (wait_for(intel_execlists_idle(dev_priv), 10))
DRM_ERROR("Timeout waiting for engines to idle\n");
 
-   for_each_engine(engine, dev_priv, id)
+   for_each_engine(engine, dev_priv, id) {
+   intel_engine_disarm_breadcrumbs(engine);
i915_gem_batch_pool_fini(>batch_pool);
+   }
 
GEM_BUG_ON(!dev_priv->gt.awake);
dev_priv->gt.awake = false;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index bc520ee8d6fe..ca8c7b22748e 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1060,6 +1060,8 @@ static void notify_ring(struct intel_engine_cs *engine)
rq = wait->request;
 
wake_up_process(wait->tsk);
+   } else {
+   __intel_engine_disarm_breadcrumbs(engine);
}
spin_unlock(>breadcrumbs.lock);
 
diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index 3855c8c39b35..ebb7bc0be9fb 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -26,19 +26,28 @@
 
 #include "i915_drv.h"
 
-unsigned int intel_engine_wakeup(struct intel_engine_cs *engine)
+static unsigned int __intel_engine_wakeup(struct intel_engine_cs *engine)
 {
struct intel_wait *wait;
-   unsigned long flags;
unsigned int result = 0;
 
-   spin_lock_irqsave(>breadcrumbs.lock, flags);
wait = engine->breadcrumbs.first_wait;
if (wait) {
result = ENGINE_WAKEUP_WAITER;
-   if (!wake_up_process(wait->tsk))
-   result |= ENGINE_WAKEUP_ACTIVE;
+   if (wake_up_process(wait->tsk))
+   result |= ENGINE_WAKEUP_ASLEEP;
}
+
+   return result;
+}
+
+unsigned int intel_engine_wakeup(struct intel_engine_cs *engine)
+{
+   unsigned long flags;
+   unsigned int result = 0;
+
+   spin_lock_irqsave(>breadcrumbs.lock, flags);
+   result = __intel_engine_wakeup(engine);
spin_unlock_irqrestore(>breadcrumbs.lock, flags);
 
return result;
@@ -54,7 +63,7 @@ static void intel_breadcrumbs_hangcheck(unsigned long data)
struct intel_engine_cs *engine = (struct intel_engine_cs *)data;
struct intel_breadcrumbs *b = >breadcrumbs;
 
-   if (!b->irq_enabled)
+   if (!b->irq_armed)
return;
 
if (b->hangcheck_interrupts != atomic_read(>irq_count)) {
@@ -67,7 +76,7 @@ static void intel_breadcrumbs_hangcheck(unsigned long data)
 * to process the pending interrupt (e.g, low priority task on a loaded
 * system) and wait until it sleeps before declaring a missed interrupt.
 */
-   if (intel_engine_wakeup(engine) & ENGINE_WAKEUP_ACTIVE) {
+   if (!(intel_engine_wakeup(engine) & ENGINE_WAKEUP_ASLEEP)) {
mod_timer(>hangcheck, wait_timeout());
return;
}
@@ -80,6 +89,8 @@ static void intel_breadcrumbs_hangcheck(unsigned long data)
 static void intel_breadcrumbs_fake_irq(unsigned long data)
 {
struct intel_engine_cs *engine = (struct intel_engine_cs *)data;
+   struct intel_breadcrumbs *b = >breadcrumbs;
+   unsigned 

Re: [Intel-gfx] [PATCH] drm/i915: Avoid tweaking evaluation thresholds on Baytrail v3

[Mika Kuoppala]

Chris Wilson  writes:

> On Wed, Feb 15, 2017 at 03:52:59PM +0200, Mika Kuoppala wrote:
>> Certain Baytrails, namely the 4 cpu core variants, have been
>> plaqued by spurious system hangs, mostly occurring with light loads.
>> 
>> Multiple bisects by various people point to a commit which changes the
>> reclocking strategy for Baytrail to follow its bigger brethen:
>> commit 8fb55197e64d ("drm/i915: Agressive downclocking on Baytrail")
>> 
>> There is also a review comment attached to this commit from Deepak S
>> on avoiding punit access on Cherryview and thus it was excluded on
>> common reclocking path. By taking the same approach and omitting
>> the punit access by not tweaking the thresholds when the hardware
>> has been asked to move into different frequency, considerable gains
>> in stability have been observed.
>> 
>> With J1900 box, light render/video load would end up in system hang
>> in usually less than 12 hours. With this patch applied, the cumulative
>> uptime has now been 34 days without issues. To provoke system hang,
>> light loads on both render and bsd engines in parallel have been used:
>> glxgears >/dev/null 2>/dev/null &
>> mpv --vo=vaapi --hwdec=vaapi --loop=inf vid.mp4
>> 
>> So far, author has not witnessed system hang with above load
>> and this patch applied. Reports from the tenacious people at
>> kernel bugzilla are also promising.
>> 
>> Considering that the punit access frequency with this patch is
>> considerably less, there is a possibility that this will push
>> the, still unknown, root cause past the triggering point on most loads.
>> 
>> But as we now can reliably reproduce the hang independently,
>> we can reduce the pain that users are having and use a
>> static thresholds until a root cause is found.
>> 
>> v3: don't break debugfs and simplification (Chris Wilson)
>> 
>> References: https://bugzilla.kernel.org/show_bug.cgi?id=109051
>> Cc: Chris Wilson 
>> Cc: Ville Syrjälä 
>> Cc: Len Brown 
>> Cc: Daniel Vetter 
>> Cc: Jani Nikula 
>> Cc: frit...@xbmc.org
>> Cc: m...@iki.fi
>> Cc: Ezequiel Garcia 
>> CC: Michal Feix 
>> Cc: Hans de Goede 
>> Cc: Deepak S 
>> Cc: Jarkko Nikula 
>> Cc:  # v4.2+
>> Acked-by: Daniel Vetter 
>> Signed-off-by: Mika Kuoppala 
>
> Had a couple of weekends to try and find an alternative explanation
> (a root cause for the hangs would be nice!). If it is just the writes to
> the RPS registers, are we safe on resume (etc)?
>
> However, I've drawn a blank on explaining what the hw is doing wrong
> (but found a couple of bugs in the byt manual RPS evaluation which
> desire review), so
> Acked-by: Chris Wilson 

Pushed, thanks.
-Mika

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

Re: [Intel-gfx] [PATCH] drm/i915/skl: Add missing SKL ID

[Mika Kuoppala]

Michał Winiarski  writes:

> Used by production device:
> Intel(R) Iris(TM) Graphics P555
>
> Cc: 
> Cc: Mika Kuoppala 
> Cc: Rodrigo Vivi 
> Signed-off-by: Michał Winiarski 
> Reviewed-by: Rodrigo Vivi 
> Reviewed-by: Mika Kuoppala 

Pushed to dinq, thanks for patch and review.
-Mika

> ---
>  include/drm/i915_pciids.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
> index a1dd21d..466c715 100644
> --- a/include/drm/i915_pciids.h
> +++ b/include/drm/i915_pciids.h
> @@ -265,7 +265,8 @@
>   INTEL_VGA_DEVICE(0x1923, info), /* ULT GT3 */ \
>   INTEL_VGA_DEVICE(0x1926, info), /* ULT GT3 */ \
>   INTEL_VGA_DEVICE(0x1927, info), /* ULT GT3 */ \
> - INTEL_VGA_DEVICE(0x192B, info)  /* Halo GT3 */ \
> + INTEL_VGA_DEVICE(0x192B, info), /* Halo GT3 */ \
> + INTEL_VGA_DEVICE(0x192D, info)  /* SRV GT3 */
>  
>  #define INTEL_SKL_GT4_IDS(info) \
>   INTEL_VGA_DEVICE(0x1932, info), /* DT GT4 */ \
> -- 
> 2.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/3] drm/i915: Only unwind the local pgtable layer if empty

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/3] drm/i915: Only unwind the local pgtable 
layer if empty
URL   : https://patchwork.freedesktop.org/series/20303/
State : success

== Summary ==

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:108  pass:95   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29 

78e102923da4589d97e202e86168d86f8251b416 drm-tip: 2017y-02m-27d-09h-37m-07s UTC 
integration manifest
6867a9f drm/i915: Remove the vma from the drm_mm if binding fails
83cf468 drm/i915: Unwind vma->pages allocation upon failure
c195b07 drm/i915: Only unwind the local pgtable layer if empty

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915: Remove temporary allocation of dma addresses when rotating

[Joonas Lahtinen]

On ma, 2017-02-27 at 10:21 +, Chris Wilson wrote:
> On Mon, Feb 27, 2017 at 10:14:12AM +, Tvrtko Ursulin wrote:
> > Perhaps you could say what kind of optimisation you have in mind to
> > save me guessing? :)
> 
> I was thinking you would like an inactivity timer. Or we could have a
> separate shrinker, as that's the principal cache management system.

My vote goes for merging and addressing the seen problems in the
caching logic.

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

[Intel-gfx] [PATCH v5] drm/i915/guc: Extract param logic form guc_init_fw()

[Arkadiusz Hiler]

Let intel_guc_init_fw() focus on determining and fetching the correct
firmware.

This patch introduces intel_uc_sanitize_options() that is called from
intel_sanitize_options().

Then, if we have GuC, we can call intel_guc_init_fw() conditionally
and we do not have to do the internal checks.

v2: fix comment, notify when nuking GuC explicitly enabled (M. Wajdeczko)
v3: fix comment again, change the nuke message (M. Wajdeczko)
v4: update title to reflect new function name + rebase
v5: text && remove 2 uneccessary checks (M. Wajeczko)

Cc: Michal Winiarski 
Cc: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Joonas Lahtinen 
Signed-off-by: Arkadiusz Hiler 
---
 drivers/gpu/drm/i915/i915_drv.c |  2 ++
 drivers/gpu/drm/i915/intel_guc_loader.c | 18 +-
 drivers/gpu/drm/i915/intel_huc.c|  3 ---
 drivers/gpu/drm/i915/intel_uc.c | 28 +++-
 drivers/gpu/drm/i915/intel_uc.h |  1 +
 5 files changed, 31 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 56624bf..7964e7f 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -993,6 +993,8 @@ static void intel_sanitize_options(struct drm_i915_private 
*dev_priv)
 
i915.semaphores = intel_sanitize_semaphores(dev_priv, i915.semaphores);
DRM_DEBUG_DRIVER("use GPU semaphores? %s\n", yesno(i915.semaphores));
+
+   intel_uc_sanitize_options(dev_priv);
 }
 
 /**
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 87b7a39..fb518e0 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -601,20 +601,7 @@ void intel_guc_init_fw(struct intel_guc *guc)
struct drm_i915_private *dev_priv = guc_to_i915(guc);
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);
-   }
-
-   if (!HAS_GUC_UCODE(dev_priv)) {
-   fw_path = NULL;
-   } else if (IS_SKYLAKE(dev_priv)) {
+   if (IS_SKYLAKE(dev_priv)) {
fw_path = I915_SKL_GUC_UCODE;
guc->fw.major_ver_wanted = SKL_FW_MAJOR;
guc->fw.minor_ver_wanted = SKL_FW_MINOR;
@@ -634,9 +621,6 @@ void intel_guc_init_fw(struct intel_guc *guc)
guc->fw.fetch_status = INTEL_UC_FIRMWARE_NONE;
guc->fw.load_status = INTEL_UC_FIRMWARE_NONE;
 
-   /* Early (and silent) return if GuC loading is disabled */
-   if (!i915.enable_guc_loading)
-   return;
if (fw_path == NULL)
return;
if (*fw_path == '\0')
diff --git a/drivers/gpu/drm/i915/intel_huc.c b/drivers/gpu/drm/i915/intel_huc.c
index 6f0811c..9707da3 100644
--- a/drivers/gpu/drm/i915/intel_huc.c
+++ b/drivers/gpu/drm/i915/intel_huc.c
@@ -162,9 +162,6 @@ void intel_huc_init_fw(struct intel_huc *huc)
huc->fw.load_status = INTEL_UC_FIRMWARE_NONE;
huc->fw.fw = INTEL_UC_FW_TYPE_HUC;
 
-   if (!HAS_HUC_UCODE(dev_priv))
-   return;
-
if (IS_SKYLAKE(dev_priv)) {
fw_path = I915_SKL_HUC_UCODE;
huc->fw.major_ver_wanted = SKL_HUC_FW_MAJOR;
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 5c204e6..7453a648 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -26,6 +26,27 @@
 #include "intel_uc.h"
 #include 
 
+void intel_uc_sanitize_options(struct drm_i915_private *dev_priv)
+{
+   if (!HAS_GUC(dev_priv)) {
+   if (i915.enable_guc_loading > 0)
+   DRM_INFO("Ignoring GuC options, no hardware");
+
+   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);
+
+   /* Can't enable guc submission without guc loaded */
+   if (!i915.enable_guc_loading)
+   i915.enable_guc_submission = 0;
+   }
+}
+
 void intel_uc_init_early(struct drm_i915_private *dev_priv)
 {
mutex_init(_priv->guc.send_mutex);
@@ -33,7 +54,12 @@ void 

Re: [Intel-gfx] [PATCH 10/10] drm/i915/uc: Add params for specifying firmware

[Joonas Lahtinen]

On pe, 2017-02-24 at 16:40 +0100, Arkadiusz Hiler wrote:
> `guc_firmware_path` and `huc_firmware_path` module parameters are added.
> 
> Using the parameter disabled version checks and loads desired firmware
> instead of the default one.
> 
> Cc: Chris Wilson 
> Cc: Joonas Lahtinen 
> Cc: Michal Winiarski 
> Signed-off-by: Arkadiusz Hiler 



> @@ -230,6 +232,14 @@ module_param_named(guc_log_level, i915.guc_log_level, 
> int, 0400);
>  MODULE_PARM_DESC(guc_log_level,
>   "GuC firmware logging level (-1:disabled (default), 0-3:enabled)");
>  
> +module_param_named(guc_firmware_path, i915.guc_firmware_path, charp, 0400);

I'm pretty sure this should be _unsafe, because it overrides the
version checks. Cc'd Jani for this.

> @@ -479,7 +479,11 @@ void intel_guc_select_fw(struct intel_guc *guc)
>   guc->fw.load_status = INTEL_UC_FIRMWARE_NONE;
>   guc->fw.fw = INTEL_UC_FW_TYPE_GUC;
>  
> - if (IS_SKYLAKE(dev_priv)) {
> + if (i915.guc_firmware_path) {
> + guc->fw.path = i915.guc_firmware_path;
> + guc->fw.major_ver_wanted = 0;
> + guc->fw.minor_ver_wanted = 0;

Or, we could keep the wanted version number, only replace the path, and
spit out WARN/taint kernel if some other version was detected?

But I guess the main purpose is to override version (not provide
request_firmware workarounds), so my vote is to make the param _unsafe.

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

[Intel-gfx] [PATCH v2] drm/i915/uc: Move intel_uc_fw_fetch() to intel_uc.c

[Arkadiusz Hiler]

The file fits better.

Additionally rename it to intel_uc_prepare_fw(), as the function does
more than simple fetch.

v2: remove second declaration, reorder (M. Wajdeczko)

Cc: Michal Wajdeczko 
Signed-off-by: Arkadiusz Hiler 
---
 drivers/gpu/drm/i915/intel_guc_loader.c | 137 +---
 drivers/gpu/drm/i915/intel_huc.c|   2 +-
 drivers/gpu/drm/i915/intel_uc.c | 135 +++
 drivers/gpu/drm/i915/intel_uc.h |   4 +-
 4 files changed, 139 insertions(+), 139 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 9f09e26..20e3337 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -26,7 +26,6 @@
  *Dave Gordon 
  *Alex Dai 
  */
-#include 
 #include "i915_drv.h"
 #include "intel_uc.h"
 
@@ -587,140 +586,6 @@ int intel_guc_init_hw(struct drm_i915_private *dev_priv)
return ret;
 }
 
-void intel_uc_fw_fetch(struct drm_i915_private *dev_priv,
-struct intel_uc_fw *uc_fw)
-{
-   struct pci_dev *pdev = dev_priv->drm.pdev;
-   struct drm_i915_gem_object *obj;
-   const struct firmware *fw = NULL;
-   struct uc_css_header *css;
-   size_t size;
-   int err;
-
-   DRM_DEBUG_DRIVER("before requesting firmware: uC fw fetch status %s\n",
-   intel_uc_fw_status_repr(uc_fw->fetch_status));
-
-   err = request_firmware(, uc_fw->path, >dev);
-   if (err)
-   goto fail;
-   if (!fw)
-   goto fail;
-
-   DRM_DEBUG_DRIVER("fetch uC fw from %s succeeded, fw %p\n",
-   uc_fw->path, fw);
-
-   /* Check the size of the blob before examining buffer contents */
-   if (fw->size < sizeof(struct uc_css_header)) {
-   DRM_NOTE("Firmware header is missing\n");
-   goto fail;
-   }
-
-   css = (struct uc_css_header *)fw->data;
-
-   /* Firmware bits always start from header */
-   uc_fw->header_offset = 0;
-   uc_fw->header_size = (css->header_size_dw - css->modulus_size_dw -
-   css->key_size_dw - css->exponent_size_dw) * sizeof(u32);
-
-   if (uc_fw->header_size != sizeof(struct uc_css_header)) {
-   DRM_NOTE("CSS header definition mismatch\n");
-   goto fail;
-   }
-
-   /* then, uCode */
-   uc_fw->ucode_offset = uc_fw->header_offset + uc_fw->header_size;
-   uc_fw->ucode_size = (css->size_dw - css->header_size_dw) * sizeof(u32);
-
-   /* now RSA */
-   if (css->key_size_dw != UOS_RSA_SCRATCH_MAX_COUNT) {
-   DRM_NOTE("RSA key size is bad\n");
-   goto fail;
-   }
-   uc_fw->rsa_offset = uc_fw->ucode_offset + uc_fw->ucode_size;
-   uc_fw->rsa_size = css->key_size_dw * sizeof(u32);
-
-   /* At least, it should have header, uCode and RSA. Size of all three. */
-   size = uc_fw->header_size + uc_fw->ucode_size + uc_fw->rsa_size;
-   if (fw->size < size) {
-   DRM_NOTE("Missing firmware components\n");
-   goto fail;
-   }
-
-   /*
-* The GuC firmware image has the version number embedded at a 
well-known
-* offset within the firmware blob; note that major / minor version are
-* TWO bytes each (i.e. u16), although all pointers and offsets are 
defined
-* in terms of bytes (u8).
-*/
-   switch (uc_fw->fw) {
-   case INTEL_UC_FW_TYPE_GUC:
-   /* Header and uCode will be loaded to WOPCM. Size of the two. */
-   size = uc_fw->header_size + uc_fw->ucode_size;
-
-   /* Top 32k of WOPCM is reserved (8K stack + 24k RC6 context). */
-   if (size > intel_guc_wopcm_size(dev_priv)) {
-   DRM_ERROR("Firmware is too large to fit in WOPCM\n");
-   goto fail;
-   }
-   uc_fw->major_ver_found = css->guc.sw_version >> 16;
-   uc_fw->minor_ver_found = css->guc.sw_version & 0x;
-   break;
-
-   case INTEL_UC_FW_TYPE_HUC:
-   uc_fw->major_ver_found = css->huc.sw_version >> 16;
-   uc_fw->minor_ver_found = css->huc.sw_version & 0x;
-   break;
-
-   default:
-   DRM_ERROR("Unknown firmware type %d\n", uc_fw->fw);
-   err = -ENOEXEC;
-   goto fail;
-   }
-
-   if (uc_fw->major_ver_found != uc_fw->major_ver_wanted ||
-   uc_fw->minor_ver_found < uc_fw->minor_ver_wanted) {
-   DRM_NOTE("uC firmware version %d.%d, required %d.%d\n",
-   uc_fw->major_ver_found, uc_fw->minor_ver_found,
-   uc_fw->major_ver_wanted, uc_fw->minor_ver_wanted);
-   err = -ENOEXEC;
-   goto fail;
-   }
-
-   

[Intel-gfx] [CI 3/3] drm/i915: Remove the vma from the drm_mm if binding fails

[Chris Wilson]

As we track whether a vma has been inserted into the drm_mm using the
vma->flags, if we fail to bind the vma into the GTT we do not update
those bits and will attempt to reinsert the vma into the drm_mm on
future passes. To prevent that, we want to unwind i915_vma_insert() if
we fail in our attempt to bind.

Fixes: 59bfa1248e22 ("drm/i915: Start passing around i915_vma from execbuffer")
Testcase: igt/drv_selftest/live_gtt
Signed-off-by: Chris Wilson 
Cc: Matthew Auld 
Cc: Joonas Lahtinen 
Cc:  # v4.9+
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_vma.c | 56 ++---
 1 file changed, 36 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 6e9eade304b8..505c1ea8d0f5 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -509,10 +509,35 @@ i915_vma_insert(struct i915_vma *vma, u64 size, u64 
alignment, u64 flags)
return ret;
 }
 
+static void
+i915_vma_remove(struct i915_vma *vma)
+{
+   struct drm_i915_gem_object *obj = vma->obj;
+
+   GEM_BUG_ON(!drm_mm_node_allocated(>node));
+   GEM_BUG_ON(vma->flags & (I915_VMA_GLOBAL_BIND | I915_VMA_LOCAL_BIND));
+
+   drm_mm_remove_node(>node);
+   list_move_tail(>vm_link, >vm->unbound_list);
+
+   /* Since the unbound list is global, only move to that list if
+* no more VMAs exist. */
+   if (--obj->bind_count == 0)
+   list_move_tail(>global_link,
+  _i915(obj->base.dev)->mm.unbound_list);
+
+   /* And finally now the object is completely decoupled from this vma,
+* we can drop its hold on the backing storage and allow it to be
+* reaped by the shrinker.
+*/
+   i915_gem_object_unpin_pages(obj);
+   GEM_BUG_ON(atomic_read(>mm.pages_pin_count) < obj->bind_count);
+}
+
 int __i915_vma_do_pin(struct i915_vma *vma,
  u64 size, u64 alignment, u64 flags)
 {
-   unsigned int bound = vma->flags;
+   const unsigned int bound = vma->flags;
int ret;
 
lockdep_assert_held(>vm->i915->drm.struct_mutex);
@@ -521,18 +546,18 @@ int __i915_vma_do_pin(struct i915_vma *vma,
 
if (WARN_ON(bound & I915_VMA_PIN_OVERFLOW)) {
ret = -EBUSY;
-   goto err;
+   goto err_unpin;
}
 
if ((bound & I915_VMA_BIND_MASK) == 0) {
ret = i915_vma_insert(vma, size, alignment, flags);
if (ret)
-   goto err;
+   goto err_unpin;
}
 
ret = i915_vma_bind(vma, vma->obj->cache_level, flags);
if (ret)
-   goto err;
+   goto err_remove;
 
if ((bound ^ vma->flags) & I915_VMA_GLOBAL_BIND)
__i915_vma_set_map_and_fenceable(vma);
@@ -541,7 +566,12 @@ int __i915_vma_do_pin(struct i915_vma *vma,
GEM_BUG_ON(i915_vma_misplaced(vma, size, alignment, flags));
return 0;
 
-err:
+err_remove:
+   if ((bound & I915_VMA_BIND_MASK) == 0) {
+   GEM_BUG_ON(vma->pages);
+   i915_vma_remove(vma);
+   }
+err_unpin:
__i915_vma_unpin(vma);
return ret;
 }
@@ -654,9 +684,6 @@ int i915_vma_unbind(struct i915_vma *vma)
}
vma->flags &= ~(I915_VMA_GLOBAL_BIND | I915_VMA_LOCAL_BIND);
 
-   drm_mm_remove_node(>node);
-   list_move_tail(>vm_link, >vm->unbound_list);
-
if (vma->pages != obj->mm.pages) {
GEM_BUG_ON(!vma->pages);
sg_free_table(vma->pages);
@@ -664,18 +691,7 @@ int i915_vma_unbind(struct i915_vma *vma)
}
vma->pages = NULL;
 
-   /* Since the unbound list is global, only move to that list if
-* no more VMAs exist. */
-   if (--obj->bind_count == 0)
-   list_move_tail(>global_link,
-  _i915(obj->base.dev)->mm.unbound_list);
-
-   /* And finally now the object is completely decoupled from this vma,
-* we can drop its hold on the backing storage and allow it to be
-* reaped by the shrinker.
-*/
-   i915_gem_object_unpin_pages(obj);
-   GEM_BUG_ON(atomic_read(>mm.pages_pin_count) < obj->bind_count);
+   i915_vma_remove(vma);
 
 destroy:
if (unlikely(i915_vma_is_closed(vma)))
-- 
2.11.0

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

[Intel-gfx] [CI 2/3] drm/i915: Unwind vma->pages allocation upon failure

[Chris Wilson]

If we fail to allocate the ppgtt range after allocating the pages for
the vma, we should unwind the local allocation before reporting back the
failure.

Fixes: ff685975d97f ("drm/i915: Move allocate_va_range to GTT")
Signed-off-by: Chris Wilson 
Cc: Matthew Auld 
Reviewed-by: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index c3a121ab8914..875a48b9d05a 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2312,7 +2312,7 @@ static int aliasing_gtt_bind_vma(struct i915_vma *vma,
 vma->node.start,
 vma->node.size);
if (ret)
-   return ret;
+   goto err_pages;
}
 
appgtt->base.insert_entries(>base,
@@ -2329,6 +2329,17 @@ static int aliasing_gtt_bind_vma(struct i915_vma *vma,
}
 
return 0;
+
+err_pages:
+   if (!(vma->flags & (I915_VMA_GLOBAL_BIND | I915_VMA_LOCAL_BIND))) {
+   if (vma->pages != vma->obj->mm.pages) {
+   GEM_BUG_ON(!vma->pages);
+   sg_free_table(vma->pages);
+   kfree(vma->pages);
+   }
+   vma->pages = NULL;
+   }
+   return ret;
 }
 
 static void aliasing_gtt_unbind_vma(struct i915_vma *vma)
-- 
2.11.0

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

[Intel-gfx] [CI 1/3] drm/i915: Only unwind the local pgtable layer if empty

[Chris Wilson]

Only if we allocated the layer and the lower level failed should we
remove this layer when unwinding. Otherwise we ignore the overlapping
entries by overwriting the old layer with scratch.

Fixes: c5d092a4293f ("drm/i915: Remove bitmap tracking for used-pml4")
Fixes: e2b763caa6eb ("drm/i915: Remove bitmap tracking for used-pdpes")
Reported-by: Matthew Auld 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99947
Testcase: igt/drv_selftest/live_gtt
Signed-off-by: Chris Wilson 
Cc: Matthew Auld 
Tested-by: Matthew Auld 
Reviewed-by: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 37 ++---
 1 file changed, 26 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 6fdbd5ae4fcb..c3a121ab8914 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -716,10 +716,13 @@ static bool gen8_ppgtt_clear_pd(struct i915_address_space 
*vm,
u32 pde;
 
gen8_for_each_pde(pt, pd, start, length, pde) {
+   GEM_BUG_ON(pt == vm->scratch_pt);
+
if (!gen8_ppgtt_clear_pt(vm, pt, start, length))
continue;
 
gen8_ppgtt_set_pde(vm, pd, vm->scratch_pt, pde);
+   GEM_BUG_ON(!pd->used_pdes);
pd->used_pdes--;
 
free_pt(vm, pt);
@@ -755,10 +758,13 @@ static bool gen8_ppgtt_clear_pdp(struct 
i915_address_space *vm,
unsigned int pdpe;
 
gen8_for_each_pdpe(pd, pdp, start, length, pdpe) {
+   GEM_BUG_ON(pd == vm->scratch_pd);
+
if (!gen8_ppgtt_clear_pd(vm, pd, start, length))
continue;
 
gen8_ppgtt_set_pdpe(vm, pdp, vm->scratch_pd, pdpe);
+   GEM_BUG_ON(!pdp->used_pdpes);
pdp->used_pdpes--;
 
free_pd(vm, pd);
@@ -801,6 +807,8 @@ static void gen8_ppgtt_clear_4lvl(struct i915_address_space 
*vm,
GEM_BUG_ON(!USES_FULL_48BIT_PPGTT(vm->i915));
 
gen8_for_each_pml4e(pdp, pml4, start, length, pml4e) {
+   GEM_BUG_ON(pdp == vm->scratch_pdp);
+
if (!gen8_ppgtt_clear_pdp(vm, pdp, start, length))
continue;
 
@@ -1089,6 +1097,7 @@ static int gen8_ppgtt_alloc_pd(struct i915_address_space 
*vm,
 
gen8_ppgtt_set_pde(vm, pd, pt, pde);
pd->used_pdes++;
+   GEM_BUG_ON(pd->used_pdes > I915_PDES);
}
 
pt->used_ptes += gen8_pte_count(start, length);
@@ -1118,21 +1127,25 @@ static int gen8_ppgtt_alloc_pdp(struct 
i915_address_space *vm,
gen8_initialize_pd(vm, pd);
gen8_ppgtt_set_pdpe(vm, pdp, pd, pdpe);
pdp->used_pdpes++;
+   GEM_BUG_ON(pdp->used_pdpes > I915_PDPES_PER_PDP(vm));
 
mark_tlbs_dirty(i915_vm_to_ppgtt(vm));
}
 
ret = gen8_ppgtt_alloc_pd(vm, pd, start, length);
-   if (unlikely(ret)) {
-   gen8_ppgtt_set_pdpe(vm, pdp, vm->scratch_pd, pdpe);
-   pdp->used_pdpes--;
-   free_pd(vm, pd);
-   goto unwind;
-   }
+   if (unlikely(ret))
+   goto unwind_pd;
}
 
return 0;
 
+unwind_pd:
+   if (!pd->used_pdes) {
+   gen8_ppgtt_set_pdpe(vm, pdp, vm->scratch_pd, pdpe);
+   GEM_BUG_ON(!pdp->used_pdpes);
+   pdp->used_pdpes--;
+   free_pd(vm, pd);
+   }
 unwind:
gen8_ppgtt_clear_pdp(vm, pdp, from, start - from);
return -ENOMEM;
@@ -1166,15 +1179,17 @@ static int gen8_ppgtt_alloc_4lvl(struct 
i915_address_space *vm,
}
 
ret = gen8_ppgtt_alloc_pdp(vm, pdp, start, length);
-   if (unlikely(ret)) {
-   gen8_ppgtt_set_pml4e(pml4, vm->scratch_pdp, pml4e);
-   free_pdp(vm, pdp);
-   goto unwind;
-   }
+   if (unlikely(ret))
+   goto unwind_pdp;
}
 
return 0;
 
+unwind_pdp:
+   if (!pdp->used_pdpes) {
+   gen8_ppgtt_set_pml4e(pml4, vm->scratch_pdp, pml4e);
+   free_pdp(vm, pdp);
+   }
 unwind:
gen8_ppgtt_clear_4lvl(vm, from, start - from);
return -ENOMEM;
-- 
2.11.0

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

Re: [Intel-gfx] [PATCH 09/10] drm/i915/uc: Separate firmware selection and preparation

[Joonas Lahtinen]

On pe, 2017-02-24 at 16:40 +0100, Arkadiusz Hiler wrote:
> intel_{h,g}uc_init_fw selects correct firmware and then triggers it's
> preparation (fetch + initial parsing).
> 
> This change separates out select steps, so those can be called by
> the sanitize_options().
> 
> Then, during the init_fw() we prepare the firmware if the firmware was
> selected.
> 
> Cc: Michal Winiarski 
> Cc: Joonas Lahtinen 
> Signed-off-by: Arkadiusz Hiler 

Reviewed-by: Joonas Lahtinen 

One comment below.

> @@ -66,6 +66,16 @@ void intel_uc_sanitize_options(struct drm_i915_private 
> *dev_priv)
>   if (!i915.enable_guc_loading)
>   i915.enable_guc_submission = 0;
>   }
> +
> + if (i915.enable_guc_loading) {
> + if (HAS_HUC_UCODE(dev_priv))
> + intel_huc_select_fw(_priv->huc);
> +
> + intel_guc_select_fw(_priv->guc);
> +
> + if (!dev_priv->guc.fw.path)
> + i915.enable_guc_loading = 0;

Maybe make this (as suggested by Michal):

if (intel_guc_select_fw(_priv->guc) < 0)
i915.enable_guc_loading = 0;

I think the select_fw is appropriate in this place once we introduce
the option to override the FW path, it'll part of sanitization.

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/skl: Add missing SKL ID (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/skl: Add missing SKL ID (rev3)
URL   : https://patchwork.freedesktop.org/series/3537/
State : success

== Summary ==

Series 3537v3 drm/i915/skl: Add missing SKL ID
https://patchwork.freedesktop.org/api/1.0/series/3537/revisions/3/mbox/

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:108  pass:95   dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29 

78e102923da4589d97e202e86168d86f8251b416 drm-tip: 2017y-02m-27d-09h-37m-07s UTC 
integration manifest
69f1560 drm/i915/skl: Add missing SKL ID

== Logs ==

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

Re: [Intel-gfx] [PATCH 1/3] drm/i915/perf: improve invalid OA format debug message

[Matthew Auld]

On 22 February 2017 at 15:25, Robert Bragg  wrote:
> A minor improvement to debugging output
>
> Signed-off-by: Robert Bragg 
Reviewed-by: Matthew Auld 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 05/10] drm/i915/uc: Introduce intel_uc_init_fw()

[Joonas Lahtinen]

On pe, 2017-02-24 at 16:39 +0100, Arkadiusz Hiler wrote:
> Instead of calling intel_guc_init() and intel_huc_init() one by one this
> patch introduces intel_uc_init_fw() function that calls them both.
> 
> Called functions are renamed accordingly.
> 
> Trying to have subject_verb_object ordering and more descriptive names,
> the intel_huc_init() and intel_guc_init() functions are renamed.
> 
> For guc_init():
>  * `intel_guc` is the subject, so those functions now take intel_guc
>    structure, instead of the dev_priv
>  * init is the verb
>  * fw is the object which better describes the function's role
> 
> huc_init() change follows the same reasoning.
> 
> v2: settle on intel_uc_fetch_fw name (M. Wajdeczko)
> v3: yet another rename - intel_uc_init_fw (J. Lahtinen)
> 
> Cc: Chris Wilson 
> Cc: Joonas Lahtinen 
> Cc: Michal Wajdeczko 
> Cc: Michal Winiarski 
> Signed-off-by: Arkadiusz Hiler 

Reviewed-by: Joonas Lahtinen 

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

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Unwind vma->pages allocation upon failure

[Matthew Auld]

On 25 February 2017 at 23:25, Chris Wilson  wrote:
> If we fail to allocate the ppgtt range after allocating the pages for
> the vma, we should unwind the local allocation before reporting back the
> failure.
>
> Fixes: ff685975d97f ("drm/i915: Move allocate_va_range to GTT")
> Signed-off-by: Chris Wilson 
> Cc: Matthew Auld 
Reviewed-by: Matthew Auld 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx