Re: [Intel-gfx] [PATCH 11/11] drm/i915/guc: Restore GuC interrupts across suspend/reset if enabled

2017-10-21 Thread Sagar Arun Kamble 



On 10/19/2017 4:33 PM, Tvrtko Ursulin wrote:


On 18/10/2017 07:47, Sagar Arun Kamble wrote:

In order to override the disable/enable control of GuC interrupts during
suspend/reset cycle we are creating two new functions suspend/restore
guc_interrupts which check if interrupts were enabled and disable them
on suspend and enable them on resume. They are used to restore 
interrupts

across reset as well.

Signed-off-by: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
---
  drivers/gpu/drm/i915/intel_display.c |  2 ++
  drivers/gpu/drm/i915/intel_guc.c | 40 


  drivers/gpu/drm/i915/intel_guc.h |  2 ++
  3 files changed, 40 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c

index 897fe7e..742ab5e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3768,8 +3768,10 @@ void intel_finish_reset(struct 
drm_i915_private *dev_priv)

   * The display has been reset as well,
   * so need a full re-initialization.
   */
+    intel_suspend_guc_interrupts(&dev_priv->guc);
  intel_runtime_pm_disable_interrupts(dev_priv);
  intel_runtime_pm_enable_interrupts(dev_priv);
+    intel_restore_guc_interrupts(&dev_priv->guc);
    intel_pps_unlock_regs_wa(dev_priv);
  intel_modeset_init_hw(dev);
diff --git a/drivers/gpu/drm/i915/intel_guc.c 
b/drivers/gpu/drm/i915/intel_guc.c

index fbd27ea..1e5abf2 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -261,6 +261,25 @@ int intel_guc_auth_huc(struct intel_guc *guc, 
u32 rsa_offset)

  return intel_guc_send(guc, action, ARRAY_SIZE(action));
  }
  +void intel_suspend_guc_interrupts(struct intel_guc *guc)
+{
+    struct drm_i915_private *dev_priv = guc_to_i915(guc);
+
+    spin_lock_irq(&dev_priv->irq_lock);
+
+    if (!guc->interrupt_clients) {
+    spin_unlock_irq(&dev_priv->irq_lock);
+    return;
+    }
+
+    gen6_disable_pm_irq(dev_priv, dev_priv->pm_guc_events);
+
+    spin_unlock_irq(&dev_priv->irq_lock);
+    synchronize_irq(dev_priv->drm.irq);
+
+    intel_reset_guc_interrupts(guc);
+}


Looks awfully similar to intel_put_guc_interrupts, minus the 
guc->interrupt_clients handling and single bit vs all. I am thinking 
if it could be consolidated somehow...


Maybe add __intel_put_guc_interrupts which does not touch 
guc->interrupt_clients and takes in a bitmask of all interrupt clients?


void __intel_put_guc_interrupts(..., unsigned long mask)
{
assert_lock_held...

if ((mask & guc->interrupt_clients) != guc->interrupt_clients)
    return;

... do the irq disable stuff..
}

void intel_suspend_guc_interrupts(...)
{
spin_lock...

__intel_put_guc_interrupts(.., guc->interrupt_clients);

spin_unlock...
}

void intel_put_guc_interrupts(..., id)
{
spin_lock...

__intel_put_guc_interrupts(.., BIT(id));
__clear_bit(guc->interrupt_clients, id);

spin_unlock...
}

Maybe some logic mistakes here, beware. :)

Sure. will update.



+
  /**
   * intel_guc_suspend() - notify GuC entering suspend state
   * @dev_priv:    i915 device private
@@ -274,8 +293,7 @@ int intel_guc_suspend(struct drm_i915_private 
*dev_priv)

  if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
  return 0;
  -    if (i915_modparams.guc_log_level >= 0)
-    intel_put_guc_interrupts(guc, GUC_INTR_CLIENT_LOG);
+    intel_suspend_guc_interrupts(guc);
    ctx = dev_priv->kernel_context;
  @@ -289,6 +307,21 @@ int intel_guc_suspend(struct drm_i915_private 
*dev_priv)

  return intel_guc_send(guc, data, ARRAY_SIZE(data));
  }
  +void intel_restore_guc_interrupts(struct intel_guc *guc)
+{
+    struct drm_i915_private *dev_priv = guc_to_i915(guc);
+
+    spin_lock_irq(&dev_priv->irq_lock);
+
+    if (guc->interrupt_clients) {
+    WARN_ON_ONCE(I915_READ(gen6_pm_iir(dev_priv)) &
+   dev_priv->pm_guc_events);
+    gen6_enable_pm_irq(dev_priv, dev_priv->pm_guc_events);
+    }
+
+    spin_unlock_irq(&dev_priv->irq_lock);
+}


And ofc something similar like the above to consolidate the 
get/restore as well.

Yes.



+
  /**
   * intel_guc_resume() - notify GuC resuming from suspend state
   * @dev_priv:    i915 device private
@@ -302,8 +335,7 @@ int intel_guc_resume(struct drm_i915_private 
*dev_priv)

  if (guc->fw.load_status != INTEL_UC_FIRMWARE_SUCCESS)
  return 0;
  -    if (i915_modparams.guc_log_level >= 0)
-    intel_get_guc_interrupts(guc, GUC_INTR_CLIENT_LOG);
+    intel_restore_guc_interrupts(guc);
    ctx = dev_priv->kernel_context;
  diff --git a/drivers/gpu/drm/i915/intel_guc.h 
b/drivers/gpu/drm/i915/intel_guc.h

index 4d58bf7..c55dcba 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -125,5 +125,7 @@ static inli

Re: [Intel-gfx] [PATCH 10/11] drm/i915/guc: Skip interrupt enabling if logging is already enabled

2017-10-21 Thread Sagar Arun Kamble 



On 10/19/2017 4:01 PM, Tvrtko Ursulin wrote:


On 18/10/2017 07:47, Sagar Arun Kamble wrote:
To balance the GuC interrupt references we don't allow enabling 
interrupts

If logging was enabled earlier with different verbosity.


I've noticed in a couple of your previous commits words in the middle 
of sentences starting with upper case which is a tiny bit distracting 
when reading.
Sorry.  Will fix those. I hope it is okay to start words like 
"GuC"/"IRQ" or acronyms with upper case.



We allow request to change log parameters to be sent to GuC though as
user may want to just update the verbosity level at runtime.

Signed-off-by: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
---
  drivers/gpu/drm/i915/intel_guc_log.c | 5 +
  1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c

index 8c41d9a..90b8caf 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -613,6 +613,11 @@ int i915_guc_log_control(struct drm_i915_private 
*dev_priv, u64 control_val)

  }
    if (log_param.logging_enabled) {
+    if (i915_modparams.guc_log_level >= 0) {
+    i915_modparams.guc_log_level = log_param.verbosity;
+    return 0;
+    }


Ok this will change if you go for the refactoring of how modparam is 
used mentioned earlier in the series.

Yes. will update.



+
  i915_modparams.guc_log_level = log_param.verbosity;
    /* If log_level was set as -1 at boot time, then the 
relay channel file




Regards,

Tvrtko


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

Re: [Intel-gfx] [PATCH 09/11] drm/i915/guc: Fix GuC interrupts disabling with Logging

2017-10-21 Thread Sagar Arun Kamble 



On 10/19/2017 3:54 PM, Tvrtko Ursulin wrote:


On 18/10/2017 07:47, Sagar Arun Kamble wrote:

With guc_log_unregister disabling runtime logging and interrupts there
is no need to disable interrupts during uc_fini_hw hence it is removed.
With GuC CT buffer mechanism, interrupt disabling can be added at a 
point

where CT mechanism ceases.

Signed-off-by: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
---
  drivers/gpu/drm/i915/intel_uc.c | 3 ---
  1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uc.c 
b/drivers/gpu/drm/i915/intel_uc.c

index d96c847..9715eda 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -287,9 +287,6 @@ void intel_uc_fini_hw(struct drm_i915_private 
*dev_priv)

    guc_disable_communication(&dev_priv->guc);
  -    if (i915_modparams.guc_log_level >= 0)
-    intel_put_guc_interrupts(&dev_priv->guc, GUC_INTR_CLIENT_LOG);
-


And this hasn't became wrong in this series right? So normally I think 
you would remove the bug before refactoring patches, just so we don't 
have to read and review in a previous patch the lines which get 
removed in the next.

Sure. Will remove this upfront.



  if (i915_modparams.enable_guc_submission)
  i915_guc_submission_fini(dev_priv);



Regards,

Tvrtko


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

Re: [Intel-gfx] [PATCH 08/11] drm/i915/guc: Add client support to enable/disable GuC interrupts

2017-10-21 Thread Sagar Arun Kamble 



On 10/19/2017 3:49 PM, Tvrtko Ursulin wrote:


On 18/10/2017 07:46, Sagar Arun Kamble wrote:

This patch adds support to enable/disable GuC interrupts for different
features without impacting others needs. Currently GuC log capture and
CT buffer receive mechanisms use the GuC interrupts. GuC interrupts are
currently enabled and disabled in different Logging scenarios all gated
by log level.

v2: Rebase with all GuC interrupt handlers moved to intel_guc.c. 
Handling

multiple clients for GuC interrupts enable/disable.
(Michal Wajdeczko)

Signed-off-by: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
---
  drivers/gpu/drm/i915/i915_debugfs.c  |  8 
  drivers/gpu/drm/i915/intel_guc.c | 21 ++---
  drivers/gpu/drm/i915/intel_guc.h | 11 ---
  drivers/gpu/drm/i915/intel_guc_log.c |  6 +++---
  drivers/gpu/drm/i915/intel_uc.c  |  6 +++---
  5 files changed, 36 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c

index 0bb6e01..bd421da 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2531,6 +2531,14 @@ static int i915_guc_info(struct seq_file *m, 
void *data)

  struct drm_i915_private *dev_priv = node_to_i915(m->private);
  const struct intel_guc *guc = &dev_priv->guc;
  +    seq_puts(m, "GuC Interrupt Clients: ");
+    spin_lock_irq(&dev_priv->irq_lock);
+    if (guc->interrupt_clients & BIT(GUC_INTR_CLIENT_LOG))


Could use test_bit.

Yes. will update


Also, spinlock not required here apart from documentation purposes?
Yes. Given the frequency of enable/disable of interrupts this spin_lock 
is not so important.



+    seq_puts(m, "GuC Logging\n");
+    else
+    seq_puts(m, "None\n");
+    spin_unlock_irq(&dev_priv->irq_lock);
+
  if (!check_guc_submission(m))
  return 0;
  diff --git a/drivers/gpu/drm/i915/intel_guc.c 
b/drivers/gpu/drm/i915/intel_guc.c

index 959057a..fbd27ea 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -275,7 +275,7 @@ int intel_guc_suspend(struct drm_i915_private 
*dev_priv)

  return 0;
    if (i915_modparams.guc_log_level >= 0)
-    intel_disable_guc_interrupts(guc);
+    intel_put_guc_interrupts(guc, GUC_INTR_CLIENT_LOG);
    ctx = dev_priv->kernel_context;
  @@ -303,7 +303,7 @@ int intel_guc_resume(struct drm_i915_private 
*dev_priv)

  return 0;
    if (i915_modparams.guc_log_level >= 0)
-    intel_enable_guc_interrupts(guc);
+    intel_get_guc_interrupts(guc, GUC_INTR_CLIENT_LOG);
    ctx = dev_priv->kernel_context;
  @@ -378,26 +378,33 @@ void intel_reset_guc_interrupts(struct 
intel_guc *guc)

  spin_unlock_irq(&dev_priv->irq_lock);
  }
  -void intel_enable_guc_interrupts(struct intel_guc *guc)
+void intel_get_guc_interrupts(struct intel_guc *guc, enum 
guc_intr_client id)

  {
  struct drm_i915_private *dev_priv = guc_to_i915(guc);
    spin_lock_irq(&dev_priv->irq_lock);
-    if (!dev_priv->guc.interrupts_enabled) {
+    if (!guc->interrupt_clients) {
  WARN_ON_ONCE(I915_READ(gen6_pm_iir(dev_priv)) &
 dev_priv->pm_guc_events);
-    dev_priv->guc.interrupts_enabled = true;
  gen6_enable_pm_irq(dev_priv, dev_priv->pm_guc_events);
  }
+    set_bit(id, &guc->interrupt_clients);


Can use __set_bit to save one atomic since it is already under the 
spinlock.

Yes.



+
  spin_unlock_irq(&dev_priv->irq_lock);
  }
  -void intel_disable_guc_interrupts(struct intel_guc *guc)
+void intel_put_guc_interrupts(struct intel_guc *guc, enum 
guc_intr_client id)

  {
  struct drm_i915_private *dev_priv = guc_to_i915(guc);
    spin_lock_irq(&dev_priv->irq_lock);
-    dev_priv->guc.interrupts_enabled = false;
+
+    clear_bit(id, &guc->interrupt_clients);


Equally as above __clear_bit would work.

Yes.



+
+    if (guc->interrupt_clients) {
+    spin_unlock_irq(&dev_priv->irq_lock);
+    return;
+    }
    gen6_disable_pm_irq(dev_priv, dev_priv->pm_guc_events);
  diff --git a/drivers/gpu/drm/i915/intel_guc.h 
b/drivers/gpu/drm/i915/intel_guc.h

index e89b4ae..4d58bf7 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -34,6 +34,11 @@
  #include "i915_guc_reg.h"
  #include "i915_vma.h"
  +enum guc_intr_client {
+    GUC_INTR_CLIENT_LOG = 0,
+    GUC_INTR_CLIENT_COUNT
+};
+
  /*
   * Top level structure of GuC. It handles firmware loading and 
manages client
   * pool and doorbells. intel_guc owns a i915_guc_client to replace 
the legacy

@@ -48,7 +53,7 @@ struct intel_guc {
  struct drm_i915_gem_object *load_err_log;
    /* intel_guc_recv interrupt related state */
-    bool interrupts_enabled;
+    unsigned long interrupt_clients;
    struct i915_vma *ads_vma;
  struct i915_vma *stage_desc_pool;
@@ -117,8 +122,8

[Intel-gfx] How To install?

2017-10-21 Thread Rhyanz 
How to install graphic card on kali linux with "00:02.0 VGA compatible
controller: Intel Corporation 2nd Generation Core Processor Family
Integrated Graphics Controller (rev 09)".

i dont know what the steps to install.
please help me.
Thanks :)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: failure for HAX: ignore fbcon entirely. ;D

2017-10-21 Thread Patchwork 
== Series Details ==

Series: HAX: ignore fbcon entirely. ;D
URL   : https://patchwork.freedesktop.org/series/32367/
State : failure

== Summary ==

Test kms_plane_multiple:
Subgroup atomic-pipe-C-tiling-none:
pass   -> INCOMPLETE (shard-hsw)
Test pm_rpm:
Subgroup pm-tiling:
pass   -> SKIP   (shard-hsw)
Test kms_plane_lowres:
Subgroup pipe-A-tiling-x:
pass   -> SKIP   (shard-hsw)
Subgroup pipe-A-tiling-none:
pass   -> SKIP   (shard-hsw)
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-spr-indfb-draw-pwrite:
pass   -> SKIP   (shard-hsw)
Subgroup fbc-1p-primscrn-spr-indfb-fullscreen:
pass   -> FAIL   (shard-hsw)
Test gem_userptr_blits:
Subgroup map-fixed-invalidate-gup:
pass   -> INCOMPLETE (shard-hsw)
Test gem_eio:
Subgroup in-flight:
pass   -> FAIL   (shard-hsw)
Subgroup in-flight-contexts:
pass   -> FAIL   (shard-hsw)
Test kms_sysfs_edid_timing:
pass   -> FAIL   (shard-hsw) fdo#100047
Test gem_mmap_wc:
Subgroup set-cache-level:
pass   -> SKIP   (shard-hsw)
Test kms_busy:
Subgroup extended-modeset-hang-oldfb-with-reset-render-A:
dmesg-warn -> PASS   (shard-hsw) fdo#102249

fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
fdo#102249 https://bugs.freedesktop.org/show_bug.cgi?id=102249

shard-hswtotal:2426 pass:1347 dwarn:1   dfail:0   fail:13  skip:1063 
time:8638s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6135/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.IGT: failure for HAX: Do not restore mode through fbcon (rev2)

2017-10-21 Thread Patchwork 
== Series Details ==

Series: HAX: Do not restore mode through fbcon (rev2)
URL   : https://patchwork.freedesktop.org/series/31893/
State : failure

== Summary ==

Test gem_mmap_wc:
Subgroup set-cache-level:
pass   -> SKIP   (shard-hsw)
Test kms_sysfs_edid_timing:
pass   -> FAIL   (shard-hsw) fdo#100047
Test kms_chv_cursor_fail:
Subgroup pipe-B-256x256-left-edge:
pass   -> INCOMPLETE (shard-hsw)
Test kms_plane_multiple:
Subgroup atomic-pipe-C-tiling-none:
pass   -> INCOMPLETE (shard-hsw)
Test gem_userptr_blits:
Subgroup map-fixed-invalidate-overlap-gup:
pass   -> DMESG-WARN (shard-hsw)
Subgroup map-fixed-invalidate-gup:
pass   -> INCOMPLETE (shard-hsw)
Test kms_setmode:
Subgroup basic:
fail   -> PASS   (shard-hsw) fdo#99912
Test kms_plane_lowres:
Subgroup pipe-A-tiling-x:
pass   -> SKIP   (shard-hsw)
Subgroup pipe-A-tiling-none:
pass   -> SKIP   (shard-hsw)
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-spr-indfb-fullscreen:
pass   -> FAIL   (shard-hsw)

fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912

shard-hswtotal:2361 pass:1309 dwarn:3   dfail:0   fail:10  skip:1036 
time:8344s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6134/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 07/11] drm/i915/guc: Grab RPM wakelock while disabling GuC interrupts

2017-10-21 Thread Sagar Arun Kamble 



On 10/19/2017 3:39 PM, Tvrtko Ursulin wrote:


On 18/10/2017 07:46, Sagar Arun Kamble wrote:

Disabling GuC interrupts involves access to GuC IRQ control registers
hence ensure device is RPM awake.

v2: Add comment about need to synchronize flush work and log runtime
 destroy

Signed-off-by: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
---
  drivers/gpu/drm/i915/intel_guc_log.c | 11 ++-
  1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c

index f87e9f5..ed239cb 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -656,8 +656,17 @@ void i915_guc_log_unregister(struct 
drm_i915_private *dev_priv)

  {
  mutex_lock(&dev_priv->drm.struct_mutex);
  /* GuC logging is currently the only user of Guc2Host 
interrupts */

-    if (i915_modparams.guc_log_level >= 0)
+    if (i915_modparams.guc_log_level >= 0) {
+    intel_runtime_pm_get(dev_priv);
  intel_disable_guc_interrupts(&dev_priv->guc);
+    intel_runtime_pm_put(dev_priv);


Is it possible to trigger the assert from I915_WRITE today and if so 
which test case?

drv_module_reload/basic-reload



+    }
+    /*
+ * TODO: Need to synchronize access to relay channel from flush 
work

+ * and release here if interrupt stays enabled from hereon.
+ * Possibly with GuC CT recv. interrupts will stay enabled until 
GEM

+ * suspend/unload.
+ */


I think we normally don't put such reminders in code. Regardless if it 
is going away in this patch series or not it looks equally pointless 
to me.
Ok. Will remove this. Will need to be noted when we add CT buf recv 
support.



guc_log_runtime_destroy(&dev_priv->guc);


Ha right, this is how the cleanup happens what I was wondering in the 
previous patch. So intel_guc_log_destroy is pretty pointless now since 
it effectively does only this. Or I missed something?
Yes. Part of intel_guc_log_destroy to unpin and release log vma is 
needed during uc_fini_hw. Will remove this function then as it is only 
used during init failure and we can open code there.



mutex_unlock(&dev_priv->drm.struct_mutex);
  }



Regards,

Tvrtko


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

[Intel-gfx] ✗ Fi.CI.BAT: failure for HAX: ignore fbcon entirely. ;D

2017-10-21 Thread Patchwork 
== Series Details ==

Series: HAX: ignore fbcon entirely. ;D
URL   : https://patchwork.freedesktop.org/series/32367/
State : failure

== Summary ==

Series 32367v1 HAX: ignore fbcon entirely. ;D
https://patchwork.freedesktop.org/api/1.0/series/32367/revisions/1/mbox/

Test chamelium:
Subgroup dp-crc-fast:
fail   -> PASS   (fi-kbl-7500u) fdo#102514
Subgroup hdmi-crc-fast:
pass   -> DMESG-WARN (fi-skl-6700k) fdo#103019
Subgroup common-hpd-after-suspend:
dmesg-warn -> PASS   (fi-kbl-7500u) fdo#102505
Test debugfs_test:
Subgroup read_all_entries:
pass   -> DMESG-WARN (fi-ilk-650)
Test gem_exec_basic:
Subgroup readonly-bsd1:
pass   -> INCOMPLETE (fi-skl-6770hq)
Test gem_exec_parallel:
Subgroup basic:
pass   -> INCOMPLETE (fi-bxt-dsi)
Test gem_exec_store:
Subgroup basic-bsd2:
pass   -> INCOMPLETE (fi-kbl-7567u)
Test gem_exec_suspend:
Subgroup basic-s3:
dmesg-warn -> PASS   (fi-cfl-s) fdo#103186
Test gem_ringfill:
Subgroup basic-default-hang:
dmesg-warn -> PASS   (fi-blb-e6850) fdo#101600 +1
Test kms_addfb_basic:
Subgroup bad-pitch-999:
pass   -> INCOMPLETE (fi-skl-6260u)
Subgroup no-handle:
pass   -> INCOMPLETE (fi-kbl-r)
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-legacy:
pass   -> FAIL   (fi-gdg-551) fdo#102618
Subgroup basic-flip-after-cursor-atomic:
pass   -> INCOMPLETE (fi-glk-1)
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-a-frame-sequence:
pass   -> INCOMPLETE (fi-skl-6700hq)
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-byt-n2820)
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-byt-n2820) fdo#101705
Test drv_module_reload:
Subgroup basic-reload:
dmesg-warn -> PASS   (fi-gdg-551) fdo#102707

fdo#102514 https://bugs.freedesktop.org/show_bug.cgi?id=102514
fdo#103019 https://bugs.freedesktop.org/show_bug.cgi?id=103019
fdo#102505 https://bugs.freedesktop.org/show_bug.cgi?id=102505
fdo#103186 https://bugs.freedesktop.org/show_bug.cgi?id=103186
fdo#101600 https://bugs.freedesktop.org/show_bug.cgi?id=101600
fdo#102618 https://bugs.freedesktop.org/show_bug.cgi?id=102618
fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705
fdo#102707 https://bugs.freedesktop.org/show_bug.cgi?id=102707

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:431s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:438s
fi-blb-e6850 total:289  pass:224  dwarn:0   dfail:0   fail:0   skip:65  
time:357s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:542s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:245s
fi-bxt-dsi   total:78   pass:60   dwarn:0   dfail:0   fail:0   skip:17 
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:495s
fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
time:476s
fi-cfl-s total:289  pass:254  dwarn:3   dfail:0   fail:0   skip:32  
time:547s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:400s
fi-gdg-551   total:289  pass:178  dwarn:0   dfail:0   fail:2   skip:109 
time:242s
fi-glk-1 total:211  pass:188  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:434s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:419s
fi-ilk-650   total:289  pass:227  dwarn:1   dfail:0   fail:0   skip:61  
time:414s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:447s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:447s
fi-kbl-7500u total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:471s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:531s
fi-kbl-7567u total:113  pass:100  dwarn:0   dfail:0   fail:0   skip:12 
fi-kbl-r total:196  pass:175  dwarn:0   dfail:0   fail:0   skip:20 
fi-pnv-d510  total:289  pass:223  dwarn:0   dfail:0   fail:0   skip:66  
time:521s
fi-skl-6260u total:184  pass:171  dwarn:0   dfail:0   fail:0   skip:12 
fi-skl-6700hqtotal:234  pass:209  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6700k total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:519s
fi-skl-6770hqtotal:49   pass:39   dwarn:0   dfail:0   fail:0   skip:9  
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:453s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0

[Intel-gfx] ✗ Fi.CI.BAT: failure for HAX: Do not restore mode through fbcon (rev2)

2017-10-21 Thread Patchwork 
== Series Details ==

Series: HAX: Do not restore mode through fbcon (rev2)
URL   : https://patchwork.freedesktop.org/series/31893/
State : failure

== Summary ==

Series 31893v2 HAX: Do not restore mode through fbcon
https://patchwork.freedesktop.org/api/1.0/series/31893/revisions/2/mbox/

Test chamelium:
Subgroup dp-crc-fast:
fail   -> PASS   (fi-kbl-7500u) fdo#102514
Subgroup hdmi-crc-fast:
pass   -> INCOMPLETE (fi-skl-6700k) fdo#103019
Subgroup common-hpd-after-suspend:
dmesg-warn -> PASS   (fi-kbl-7500u) fdo#102505
Test debugfs_test:
Subgroup read_all_entries:
pass   -> DMESG-WARN (fi-ilk-650)
Test gem_exec_nop:
Subgroup basic-parallel:
pass   -> INCOMPLETE (fi-bxt-j4205)
Test gem_exec_parse:
Subgroup basic-allowed:
skip   -> INCOMPLETE (fi-skl-gvtdvm)
Test gem_exec_store:
Subgroup basic-bsd:
pass   -> INCOMPLETE (fi-cfl-s)
Subgroup basic-render:
pass   -> INCOMPLETE (fi-kbl-7567u)
Test gem_exec_suspend:
Subgroup basic-s3:
pass   -> DMESG-FAIL (fi-kbl-7560u) fdo#103039
Subgroup basic-s4-devices:
pass   -> DMESG-WARN (fi-byt-n2820)
pass   -> DMESG-FAIL (fi-kbl-7560u) fdo#102846 +1
Test gem_flink_basic:
Subgroup bad-flink:
pass   -> DMESG-WARN (fi-kbl-7560u) fdo#103049 +4
Test gem_mmap:
Subgroup basic:
pass   -> DMESG-WARN (fi-kbl-7560u)
Subgroup basic-small-bo:
pass   -> DMESG-WARN (fi-kbl-7560u)
Test gem_mmap_gtt:
Subgroup basic:
pass   -> DMESG-WARN (fi-kbl-7560u)
Subgroup basic-copy:
pass   -> DMESG-WARN (fi-kbl-7560u)
Subgroup basic-read:
pass   -> DMESG-WARN (fi-kbl-7560u)
Subgroup basic-read-no-prefault:
pass   -> DMESG-WARN (fi-kbl-7560u)
Subgroup basic-read-write:
pass   -> DMESG-WARN (fi-kbl-7560u)
Subgroup basic-read-write-distinct:
pass   -> DMESG-WARN (fi-kbl-7560u)
Subgroup basic-short:
pass   -> DMESG-WARN (fi-kbl-7560u)
Subgroup basic-small-bo:
pass   -> DMESG-WARN (fi-kbl-7560u)
Subgroup basic-small-bo-tiledx:
pass   -> DMESG-WARN (fi-kbl-7560u)
Subgroup basic-small-bo-tiledy:
pass   -> DMESG-WARN (fi-kbl-7560u)
Subgroup basic-small-copy:
pass   -> DMESG-WARN (fi-kbl-7560u)
Subgroup basic-small-copy-xy:
pass   -> DMESG-WARN (fi-kbl-7560u)
Subgroup basic-wc:
pass   -> DMESG-WARN (fi-kbl-7560u)
Subgroup basic-write:
pass   -> INCOMPLETE (fi-kbl-7560u)
Test gem_ringfill:
Subgroup basic-default-hang:
dmesg-warn -> PASS   (fi-blb-e6850) fdo#101600 +1
Test kms_addfb_basic:
Subgroup addfb25-x-tiled:
pass   -> INCOMPLETE (fi-skl-6770hq)
Subgroup invalid-set-prop:
pass   -> INCOMPLETE (fi-skl-6260u)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-byt-n2820) fdo#101705
Test drv_module_reload:
Subgroup basic-reload:
dmesg-warn -> PASS   (fi-gdg-551) fdo#102707

fdo#102514 https://bugs.freedesktop.org/show_bug.cgi?id=102514
fdo#103019 https://bugs.freedesktop.org/show_bug.cgi?id=103019
fdo#102505 https://bugs.freedesktop.org/show_bug.cgi?id=102505
fdo#103039 https://bugs.freedesktop.org/show_bug.cgi?id=103039
fdo#102846 https://bugs.freedesktop.org/show_bug.cgi?id=102846
fdo#103049 https://bugs.freedesktop.org/show_bug.cgi?id=103049
fdo#101600 https://bugs.freedesktop.org/show_bug.cgi?id=101600
fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705
fdo#102707 https://bugs.freedesktop.org/show_bug.cgi?id=102707

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:438s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:438s
fi-blb-e6850 total:289  pass:224  dwarn:0   dfail:0   fail:0   skip:65  
time:363s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:547s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:248s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:515s
fi-bxt-j4205 total:76   pass:59   dwarn:0   dfail:0   fail:0   skip:16 
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:508s
WARNING: Long output truncated

fcd4cd0d6182714b9ab0b5bb9139a06e6378b8ce drm-tip: 2017y-10m-20d-23h-22m-54s UTC 
integration manifest
d5527e25b92a HAX: Do not restore mode t

Re: [Intel-gfx] [PATCH 04/11] drm/i915/guc: Sanitize module parameter guc_log_level

2017-10-21 Thread Sagar Arun Kamble 



On 10/19/2017 12:52 PM, Tvrtko Ursulin wrote:


On 18/10/2017 16:50, Sagar Arun Kamble wrote:

On 10/18/2017 6:29 PM, Tvrtko Ursulin wrote:


On 18/10/2017 07:46, Sagar Arun Kamble wrote:

Parameter guc_log_level needs to be sanitized based on GuC support and
enable_guc_loading parameter since it depends on them like
enable_guc_submission. This will make GuC logging paths independent of
enable_guc_submission parameter in further patches.

v2: Added documentation to intel_guc_log.c and param description about
GuC loading dependency. (Michal Wajdeczko)

Signed-off-by: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
---
  drivers/gpu/drm/i915/i915_params.c   |  4 +++-
  drivers/gpu/drm/i915/intel_guc_log.c |  1 +
  drivers/gpu/drm/i915/intel_uc.c  | 10 +++---
  3 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c

index b4faeb6..774c56e 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -171,7 +171,9 @@ struct i915_params i915_modparams __read_mostly 
= {

  "(-1=auto, 0=never [default], 1=if available, 2=required)");
    i915_param_named(guc_log_level, int, 0400,
-    "GuC firmware logging level (-1:disabled (default), 
0-3:enabled)");
+    "GuC firmware logging level. This takes effect only if GuC is 
to be "

+    "loaded (depends on enable_guc_loading) (-1:disabled (default), "
+    "0-3:enabled)");
    i915_param_named_unsafe(guc_firmware_path, charp, 0400,
  "GuC firmware path to use instead of the default one");
diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c

index f53c663..200f0a1 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -34,6 +34,7 @@
   * DOC: GuC firmware log
   *
   * Firmware log is enabled by setting i915.guc_log_level to 
non-negative level.
+ * This takes effect only if GuC is to be loaded based on 
enable_guc_loading.
   * Log data is printed out via reading debugfs i915_guc_log_dump. 
Reading from
   * i915_guc_load_status will print out firmware loading status 
and scratch

   * registers value.
diff --git a/drivers/gpu/drm/i915/intel_uc.c 
b/drivers/gpu/drm/i915/intel_uc.c

index 62738ad..8feefcd 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -51,11 +51,13 @@ void intel_uc_sanitize_options(struct 
drm_i915_private *dev_priv)

  {
  if (!HAS_GUC(dev_priv)) {
  if (i915_modparams.enable_guc_loading > 0 ||
-    i915_modparams.enable_guc_submission > 0)
+    i915_modparams.enable_guc_submission > 0 ||
+    i915_modparams.guc_log_level > 0)
  DRM_INFO("Ignoring GuC options, no hardware\n");


Hm, this won't fire on <=gen8 once enable_guc_submission starts to 
default to one? Or we can worry about that when we get there...

This will fire for <=gen8 for +ve values which is expected.



i915_modparams.enable_guc_loading = 0;
  i915_modparams.enable_guc_submission = 0;
+    i915_modparams.guc_log_level = -1;
  return;
  }
  @@ -72,9 +74,11 @@ void intel_uc_sanitize_options(struct 
drm_i915_private *dev_priv)

  i915_modparams.enable_guc_loading = 0;
  }
  -    /* Can't enable guc submission without guc loaded */
-    if (!i915_modparams.enable_guc_loading)
+    /* Can't enable guc submission and logging without guc loaded */
+    if (!i915_modparams.enable_guc_loading) {
  i915_modparams.enable_guc_submission = 0;
+    i915_modparams.guc_log_level = -1;


Hm2, how does this interact with the changes which are removing 
enable_guc_loading? Or it is a race?
It interacts. Will race. I think I should pause this series till the 
other one gets merged.


Okay, it's your call (as in you guys who are refactoring GuC heavily 
at the moment).


Should I continue to the end of this one then? It is not that big so I 
just as well can.
Thanks for the review. Will address all the inputs and post after 
Sujaritha's series as there will be some conflict.
I had thought of having this review in parallel as patches are largely 
independent but still there is some conflict so I

will defer next rev. for some more time.


Regards,

Tvrtko


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

Re: [Intel-gfx] [PATCH 06/11] drm/i915/guc: Only release GuC log object during submission_fini

2017-10-21 Thread Sagar Arun Kamble 



On 10/19/2017 12:48 PM, Tvrtko Ursulin wrote:


On 18/10/2017 17:04, Sagar Arun Kamble wrote:

On 10/18/2017 6:42 PM, Tvrtko Ursulin wrote:


On 18/10/2017 07:46, Sagar Arun Kamble wrote:

GuC log runtime/relay channel data is released during i915 unregister,
So only GuC log vma needs to be released during submission_fini.

Signed-off-by: Sagar Arun Kamble 
Cc: Michal Wajdeczko 
Cc: Daniele Ceraolo Spurio 
Cc: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
---
  drivers/gpu/drm/i915/i915_guc_submission.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c

index a2e8114..c360b37 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -1021,7 +1021,7 @@ void i915_guc_submission_fini(struct 
drm_i915_private *dev_priv)

    ida_destroy(&guc->stage_ids);
  guc_ads_destroy(guc);
-    intel_guc_log_destroy(guc);
+    i915_vma_unpin_and_release(&guc->log.vma);
i915_gem_object_unpin_map(guc->stage_desc_pool->obj);
i915_vma_unpin_and_release(&guc->stage_desc_pool);
  }



Doesn't it make more sense to hide the logging implementation 
details from this call site?

Yes right. Will need to separate logging from submission cleanup here.


And I can't find the remaining caller of the intel_guc_log_destroy 
in the current codebase? Unless it was added in one of the previous 
patches?
It is called during submission_init on failure and that too will need 
to be changed as we separate logging from submission.


But never gets to run on driver unload? By design or oversight?

Oversight. Never gets to run on driver unload.


Regards,

Tvrtko


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