Re: [Intel-gfx] [PATCH 19/38] drm/hisilicon: Implement some semblance of vblank event handling

[Xinliang Liu]

On 21 June 2016 at 15:19, Daniel Vetter  wrote:
> On Tue, Jun 21, 2016 at 3:32 AM, Xinliang Liu  wrote:
>> My understanding is that drm_crtc_arm_vblank_event work together with
>> drm_crtc_handle_vblank (called in vblank interrupt).
>> Arm the event first in somewhere(like atomic_begin/flush) and then
>> send it out throuth drm_crtc_handle_vblank in vblank interrupt.
>> In the other way, drm_crtc_send_vblank_event work together with flip
>> interrupt. That's means event will be sent in flip interrupt
>> immediately.
>> Is this right?
>
> First part is right. Second part about drm_crtc_send_vblank event just
> sends out the vblank directly (using the last recorded vblank). The
> vblank subsystem doesn't itself interact with any interrupt.
>
> Note that there's kerneldoc for all of this. Please make sure it does
> describe things sufficiently well, and if not please send in patches
> to improve them.

Ok, I will take a look at the doc.

Thanks,
-xinliang

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

[Intel-gfx] linux-next: manual merge of the drm-misc tree with the arm tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-misc tree got a conflict in:

  drivers/gpu/drm/sti/sti_drv.c

between commit:

  062993b15e8e ("drm: convert DT component matching to 
component_match_add_release()")

from the arm tree and commit:

  84601dbdea36 ("drm: sti: rework init sequence")

from the drm-misc tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/sti/sti_drv.c
index 8abb57a94651,96bd3d08b2d4..
--- a/drivers/gpu/drm/sti/sti_drv.c
+++ b/drivers/gpu/drm/sti/sti_drv.c
@@@ -340,14 -320,79 +320,84 @@@ static int compare_of(struct device *de
return dev->of_node == data;
  }
  
 +static void release_of(struct device *dev, void *data)
 +{
 +  of_node_put(data);
 +}
 +
+ static int sti_init(struct drm_device *ddev)
+ {
+   struct sti_private *private;
+ 
+   private = kzalloc(sizeof(*private), GFP_KERNEL);
+   if (!private)
+   return -ENOMEM;
+ 
+   ddev->dev_private = (void *)private;
+   dev_set_drvdata(ddev->dev, ddev);
+   private->drm_dev = ddev;
+ 
+   mutex_init(>commit.lock);
+   INIT_WORK(>commit.work, sti_atomic_work);
+ 
+   drm_mode_config_init(ddev);
+ 
+   sti_mode_config_init(ddev);
+ 
+   drm_kms_helper_poll_init(ddev);
+ 
+   return 0;
+ }
+ 
+ static void sti_cleanup(struct drm_device *ddev)
+ {
+   struct sti_private *private = ddev->dev_private;
+ 
+   if (private->fbdev) {
+   drm_fbdev_cma_fini(private->fbdev);
+   private->fbdev = NULL;
+   }
+ 
+   drm_kms_helper_poll_fini(ddev);
+   drm_vblank_cleanup(ddev);
+   kfree(private);
+   ddev->dev_private = NULL;
+ }
+ 
  static int sti_bind(struct device *dev)
  {
-   return drm_platform_init(_driver, to_platform_device(dev));
+   struct drm_device *ddev;
+   int ret;
+ 
+   ddev = drm_dev_alloc(_driver, dev);
+   if (!ddev)
+   return -ENOMEM;
+ 
+   ddev->platformdev = to_platform_device(dev);
+ 
+   ret = sti_init(ddev);
+   if (ret)
+   goto err_drm_dev_unref;
+ 
+   ret = component_bind_all(ddev->dev, ddev);
+   if (ret)
+   goto err_cleanup;
+ 
+   ret = drm_dev_register(ddev, 0);
+   if (ret)
+   goto err_register;
+ 
+   drm_mode_config_reset(ddev);
+ 
+   return 0;
+ 
+ err_register:
+   drm_mode_config_cleanup(ddev);
+ err_cleanup:
+   sti_cleanup(ddev);
+ err_drm_dev_unref:
+   drm_dev_unref(ddev);
+   return ret;
  }
  
  static void sti_unbind(struct device *dev)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-intel tree got a conflict in:

  drivers/gpu/drm/i915/intel_fbc.c

between commit:

  1e3fa0acfec6 ("drm/i915/fbc: Disable on HSW by default for now")

from the drm-intel-fixes tree and commit:

  80788a0fbbdf ("drm/i915/fbc: sanitize i915.enable_fbc during FBC init")

from the drm-intel tree.

I fixed it up (since the former patch appears on both trees, I just
used the latter) and can carry the fix as necessary. This is now fixed
as far as linux-next is concerned, but any non trivial conflicts should
be mentioned to your upstream maintainer when your tree is submitted for
merging.  You may also want to consider cooperating with the maintainer
of the conflicting tree to minimise any particularly complex conflicts.

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

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

[Antoine, Peter]

Hi Rodrigo,

I tested with an old version that has been knocking about for ages. It is 
shipped on Android so I think it is production. I may be wrong there as Tom was 
handling the firmware release process and is not available to talk to.

I am being "ACT'ed"/"ACT'ioned"*, so am not sure when I'll stop having access 
to the firmware/hardware, so added the BXT patch so it was available to others, 
it has been tested on multiple platforms/kernels including being tested on 
media enabled platforms.

I have seen the skl huc version with the full version and build. I am not sure 
what the release version of the BXT HuC will be. It might be worth simply 
dropping the BXT patch (after review) so that when the correct firmware is 
released we have a tested/reviewed version of the code to base the changes on.

I think Chris Harris, is trying to organize the firmware releases/packaging, 
but the release process and structure is still up in the air a little. It might 
be worth contacting him directly to find out the  correct version and if there 
is a releasable version for BXT.

Peter

*still under review (the position and not just the correct verb to use :) ).

-Original Message-
From: Vivi, Rodrigo 
Sent: Tuesday, June 21, 2016 7:26 PM
To: intel-gfx@lists.freedesktop.org; Antoine, Peter 
Cc: Prigent, Christophe ; Kelley, Sean V 
; Gordon, David S ; Li, 
Lawrence T 
Subject: Re: [PATCH 6/6] drm/i915/huc: Add BXT HuC Loading Support

Hi Peter,

On Tue, 2016-06-21 at 19:11 +0100, Peter Antoine wrote:
> This patch adds the HuC Loading for the BXT.
> Version 1.x of the HuC firmware.
> 
> Signed-off-by: Peter Antoine 
> ---
>  drivers/gpu/drm/i915/i915_gem.c | 13 +++--
>  drivers/gpu/drm/i915/intel_guc_loader.c | 29 +
> 
>  drivers/gpu/drm/i915/intel_huc_loader.c |  7 +++
>  3 files changed, 27 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> b/drivers/gpu/drm/i915/i915_gem.c index 549dd3f..6abd5e5 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -5143,16 +5143,9 @@ i915_gem_init_hw(struct drm_device *dev)
>   intel_mocs_init_l3cc_table(dev);
>  
>   /* We can't enable contexts until all firmware is loaded */
> - if (HAS_GUC(dev)) {
> - /* init WOPCM */
> - I915_WRITE(GUC_WOPCM_SIZE, guc_wopcm_size(dev));
> - I915_WRITE(DMA_GUC_WOPCM_OFFSET,
> GUC_WOPCM_OFFSET_VALUE);
> -
> - intel_huc_load(dev);
> - ret = intel_guc_setup(dev);
> - if (ret)
> - goto out;
> - }
> + ret = intel_guc_setup(dev);
> + if (ret)
> + goto out;
>  
>   /*
>    * Increment the next seqno by 0x100 so we have a visible break diff 
> --git a/drivers/gpu/drm/i915/intel_guc_loader.c
> b/drivers/gpu/drm/i915/intel_guc_loader.c
> index e876a23f..289b5b6 100644
> --- a/drivers/gpu/drm/i915/intel_guc_loader.c
> +++ b/drivers/gpu/drm/i915/intel_guc_loader.c
> @@ -82,6 +82,17 @@ const char *intel_uc_fw_status_repr(enum 
> intel_uc_fw_status status)
>   }
>  };
>  
> +u32 guc_wopcm_size(struct drm_device *dev) {
> + u32 wopcm_size = GUC_WOPCM_TOP;
> +
> + /* On BXT, the top of WOPCM is reserved for RC6 context */
> + if (IS_BROXTON(dev))
> + wopcm_size -= BXT_GUC_WOPCM_RC6_RESERVED;
> +
> + return wopcm_size;
> +}
> +
>  static void direct_interrupts_to_host(struct drm_i915_private
> *dev_priv)
>  {
>   struct intel_engine_cs *engine;
> @@ -296,17 +307,6 @@ static int guc_ucode_xfer_dma(struct 
> drm_i915_private *dev_priv)
>   return ret;
>  }
>  
> -u32 guc_wopcm_size(struct drm_device *dev) -{
> - u32 wopcm_size = GUC_WOPCM_TOP;
> -
> - /* On BXT, the top of WOPCM is reserved for RC6 context */
> - if (IS_BROXTON(dev))
> - wopcm_size -= BXT_GUC_WOPCM_RC6_RESERVED;
> -
> - return wopcm_size;
> -}
> -
>  /*
>   * Load the GuC firmware blob into the MinuteIA.
>   */
> @@ -333,6 +333,10 @@ static int guc_ucode_xfer(struct drm_i915_private 
> *dev_priv)
>  
>   intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
>  
> + /* init WOPCM */
> + I915_WRITE(GUC_WOPCM_SIZE, guc_wopcm_size(dev));
> + I915_WRITE(DMA_GUC_WOPCM_OFFSET, GUC_WOPCM_OFFSET_VALUE);
> +
>   /* Enable MIA caching. GuC clock gating is disabled. */
>   I915_WRITE(GUC_SHIM_CONTROL, GUC_SHIM_CONTROL_VALUE);
>  
> @@ -483,6 +487,7 @@ int intel_guc_setup(struct drm_device *dev)
>   goto fail;
>   }
>  
> + intel_huc_load(dev);
>   err = guc_ucode_xfer(dev_priv);
>   if (!err)
>   break;
> @@ -638,7 +643,7 @@ void intel_uc_fw_fetch(struct drm_device *dev, 
> struct intel_uc_fw *uc_fw)
>   size 

[Intel-gfx] [PATCH v6 3/4] drm/i915/vlv: Disable HPD in valleyview_crt_detect_hotplug()

[Lyude]

One of the things preventing us from using polling is the fact that
calling valleyview_crt_detect_hotplug() when there's a VGA cable
connected results in sending another hotplug. With polling enabled when
HPD is disabled, this results in a scenario like this:

- We enable power wells and reset the ADPA
- output_poll_exec does force probe on VGA, triggering a hpd
- HPD handler waits for poll to unlock dev->mode_config.mutex
- output_poll_exec shuts off the ADPA, unlocks dev->mode_config.mutex
- HPD handler runs, resets ADPA and brings us back to the start

This results in an endless irq storm getting sent from the ADPA
whenever a VGA connector gets detected in the middle of polling.

Somewhat based off of the "drm/i915: Disable CRT HPD around force
trigger" patch Ville Syrjälä sent a while back

Cc: sta...@vger.kernel.org
Cc: Ville Syrjälä 
Signed-off-by: Lyude 
---
 drivers/gpu/drm/i915/i915_drv.h  |  2 ++
 drivers/gpu/drm/i915/intel_crt.c | 18 ++
 drivers/gpu/drm/i915/intel_hotplug.c | 27 +++
 3 files changed, 47 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a988a95..239a3ec 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2933,6 +2933,8 @@ void intel_hpd_init(struct drm_i915_private *dev_priv);
 void intel_hpd_init_work(struct drm_i915_private *dev_priv);
 void intel_hpd_cancel_work(struct drm_i915_private *dev_priv);
 bool intel_hpd_pin_to_port(enum hpd_pin pin, enum port *port);
+bool intel_hpd_disable(struct drm_i915_private *dev_priv, enum hpd_pin pin);
+void intel_hpd_enable(struct drm_i915_private *dev_priv, enum hpd_pin pin);
 
 /* i915_irq.c */
 void i915_queue_hangcheck(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 220be7a..a626793 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -327,10 +327,25 @@ static bool valleyview_crt_detect_hotplug(struct 
drm_connector *connector)
struct drm_device *dev = connector->dev;
struct intel_crt *crt = intel_attached_crt(connector);
struct drm_i915_private *dev_priv = dev->dev_private;
+   bool reenable_hpd;
u32 adpa;
bool ret;
u32 save_adpa;
 
+   /*
+* Doing a force trigger causes a hpd interrupt to get sent, which can
+* get us stuck in a loop if we're polling:
+*  - We enable power wells and reset the ADPA
+*  - output_poll_exec does force probe on VGA, triggering a hpd
+*  - HPD handler waits for poll to unlock dev->mode_config.mutex
+*  - output_poll_exec shuts off the ADPA, unlocks
+*dev->mode_config.mutex
+*  - HPD handler runs, resets ADPA and brings us back to the start
+*
+* Just disable HPD interrupts here to prevent this
+*/
+   reenable_hpd = intel_hpd_disable(dev_priv, crt->base.hpd_pin);
+
save_adpa = adpa = I915_READ(crt->adpa_reg);
DRM_DEBUG_KMS("trigger hotplug detect cycle: adpa=0x%x\n", adpa);
 
@@ -353,6 +368,9 @@ static bool valleyview_crt_detect_hotplug(struct 
drm_connector *connector)
 
DRM_DEBUG_KMS("valleyview hotplug adpa=0x%x, result %d\n", adpa, ret);
 
+   if (reenable_hpd)
+   intel_hpd_enable(dev_priv, crt->base.hpd_pin);
+
return ret;
 }
 
diff --git a/drivers/gpu/drm/i915/intel_hotplug.c 
b/drivers/gpu/drm/i915/intel_hotplug.c
index 38eeca7..ec3285f 100644
--- a/drivers/gpu/drm/i915/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/intel_hotplug.c
@@ -510,3 +510,30 @@ void intel_hpd_cancel_work(struct drm_i915_private 
*dev_priv)
cancel_work_sync(_priv->hotplug.hotplug_work);
cancel_delayed_work_sync(_priv->hotplug.reenable_work);
 }
+
+bool intel_hpd_disable(struct drm_i915_private *dev_priv, enum hpd_pin pin)
+{
+   bool ret = false;
+
+   if (pin == HPD_NONE)
+   return false;
+
+   spin_lock_irq(_priv->irq_lock);
+   if (dev_priv->hotplug.stats[pin].state == HPD_ENABLED) {
+   dev_priv->hotplug.stats[pin].state = HPD_DISABLED;
+   ret = true;
+   }
+   spin_unlock_irq(_priv->irq_lock);
+
+   return ret;
+}
+
+void intel_hpd_enable(struct drm_i915_private *dev_priv, enum hpd_pin pin)
+{
+   if (pin == HPD_NONE)
+   return;
+
+   spin_lock_irq(_priv->irq_lock);
+   dev_priv->hotplug.stats[pin].state = HPD_ENABLED;
+   spin_unlock_irq(_priv->irq_lock);
+}
-- 
2.5.5

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

[Intel-gfx] [PATCH v6 2/4] drm/i915/vlv: Reset the ADPA in vlv_display_power_well_init()

[Lyude]

While VGA hotplugging worked(ish) before, it looks like that was mainly
because we'd unintentionally enable it in
valleyview_crt_detect_hotplug() when we did a force trigger. This
doesn't work reliably enough because whenever the display powerwell on
vlv gets disabled, the values set in VLV_ADPA get cleared and
consequently VGA hotplugging gets disabled. This causes bugs such as one
we found on an Intel NUC, where doing the following sequence of
hotplugs:

  - Disconnect all monitors
  - Connect VGA
  - Disconnect VGA
  - Connect HDMI

Would result in VGA hotplugging becoming disabled, due to the powerwells
getting toggled in the process of connecting HDMI.

Changes since v3:
 - Expose intel_crt_reset() through intel_drv.h and call that in
   vlv_display_power_well_init() instead of
   encoder->base.funcs->reset(>base);

Changes since v2:
 - Use intel_encoder structs instead of drm_encoder structs

Changes since v1:
 - Instead of handling the register writes ourself, we just reuse
   intel_crt_detect()
 - Instead of resetting the ADPA during display IRQ installation, we now
   reset them in vlv_display_power_well_init()

Cc: sta...@vger.kernel.org
Acked-by: Daniel Vetter 
Signed-off-by: Lyude 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_crt.c| 2 +-
 drivers/gpu/drm/i915/intel_drv.h| 2 +-
 drivers/gpu/drm/i915/intel_runtime_pm.c | 7 +++
 3 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index dfcd718..220be7a 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -713,7 +713,7 @@ static int intel_crt_set_property(struct drm_connector 
*connector,
return 0;
 }
 
-static void intel_crt_reset(struct drm_encoder *encoder)
+void intel_crt_reset(struct drm_encoder *encoder)
 {
struct drm_device *dev = encoder->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 496c962..dcbfdde 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1075,7 +1075,7 @@ void gen8_irq_power_well_pre_disable(struct 
drm_i915_private *dev_priv,
 
 /* intel_crt.c */
 void intel_crt_init(struct drm_device *dev);
-
+void intel_crt_reset(struct drm_encoder *encoder);
 
 /* intel_ddi.c */
 void intel_ddi_clk_select(struct intel_encoder *encoder,
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index e856d49..f88ef76 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -1065,6 +1065,7 @@ static void vlv_init_display_clock_gating(struct 
drm_i915_private *dev_priv)
 
 static void vlv_display_power_well_init(struct drm_i915_private *dev_priv)
 {
+   struct intel_encoder *encoder;
enum pipe pipe;
 
/*
@@ -1100,6 +1101,12 @@ static void vlv_display_power_well_init(struct 
drm_i915_private *dev_priv)
 
intel_hpd_init(dev_priv);
 
+   /* Re-enable the ADPA, if we have one */
+   for_each_intel_encoder(dev_priv->dev, encoder) {
+   if (encoder->type == INTEL_OUTPUT_ANALOG)
+   intel_crt_reset(>base);
+   }
+
i915_redisable_vga_power_on(dev_priv->dev);
 }
 
-- 
2.5.5

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

[Intel-gfx] [PATCH v6 0/4] Fixes for HPD

[Lyude]

Latest version of:

https://lists.freedesktop.org/archives/intel-gfx/2016-June/098787.html

The only patch that's changed here is 4/4, the rest are just being sent so that
they can be in one thread to make things easier for reviewers

Lyude (4):
  drm/i915/vlv: Make intel_crt_reset() per-encoder
  drm/i915/vlv: Reset the ADPA in vlv_display_power_well_init()
  drm/i915/vlv: Disable HPD in valleyview_crt_detect_hotplug()
  drm/i915: Enable polling when we don't have hpd

 drivers/gpu/drm/i915/i915_drv.c |   3 +
 drivers/gpu/drm/i915/i915_drv.h |   5 ++
 drivers/gpu/drm/i915/intel_crt.c|  28 ++--
 drivers/gpu/drm/i915/intel_drv.h|   4 +-
 drivers/gpu/drm/i915/intel_hotplug.c| 117 
 drivers/gpu/drm/i915/intel_runtime_pm.c |   9 +++
 6 files changed, 148 insertions(+), 18 deletions(-)

-- 
2.5.5

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

[Intel-gfx] [PATCH v6 4/4] drm/i915: Enable polling when we don't have hpd

[Lyude]

Unfortunately, there's two situations where we lose hpd right now:
- Runtime suspend
- When we've shut off all of the power wells on Valleyview/Cherryview

While it would be nice if this didn't cause issues, this has the
ability to get us in some awkward states where a user won't be able to
get their display to turn on. For instance; if we boot a Valleyview
system without any monitors connected, it won't need any of it's power
wells and thus shut them off. Since this causes us to lose HPD, this
means that unless the user knows how to ssh into their machine and do a
manual reprobe for monitors, none of the monitors they connect after
booting will actually work.

Eventually we should come up with a better fix then having to enable
polling for this, since this makes rpm a lot less useful, but for now
the infrastructure in i915 just isn't there yet to get hpd in these
situations.

Changes since v1:
 - Add comment explaining the addition of the if
   (!mode_config->poll_running) in intel_hpd_init()
 - Remove unneeded if (!dev->mode_config.poll_enabled) in
   i915_hpd_poll_init_work()
 - Call to drm_helper_hpd_irq_event() after we disable polling
 - Add cancel_work_sync() call to intel_hpd_cancel_work()

Changes since v2:
 - Apparently dev->mode_config.poll_running doesn't actually reflect
   whether or not a poll is currently in progress, and is actually used
   for dynamic module paramter enabling/disabling. So now we instead
   keep track of our own poll_running variable in dev_priv->hotplug
 - Clean i915_hpd_poll_init_work() a little bit

Changes since v3:
 - Remove the now-redundant connector loop in intel_hpd_init(), just
   rely on intel_hpd_poll_enable() for setting connector->polled
   correctly on each connector
 - Get rid of poll_running
 - Don't assign enabled in i915_hpd_poll_init_work before we actually
   lock dev->mode_config.mutex
 - Wrap enabled assignment in i915_hpd_poll_init_work() in READ_ONCE()
   for doc purposes
 - Do the same for dev_priv->hotplug.poll_enabled with WRITE_ONCE in
   intel_hpd_poll_enable()
 - Add some comments about racing not mattering in intel_hpd_poll_enable

Changes since v4:
 - Rename intel_hpd_poll_enable() to intel_hpd_poll_init()
 - Drop the bool argument from intel_hpd_poll_init()
 - Remove redundant calls to intel_hpd_poll_init()
 - Rename poll_enable_work to poll_init_work
 - Add some kerneldoc for intel_hpd_poll_init()
 - Cross-reference intel_hpd_poll_init() in intel_hpd_init()
 - Just copy the loop from intel_hpd_init() in intel_hpd_poll_init()

Changes since v5:
 - Minor kerneldoc nitpicks

Cc: sta...@vger.kernel.org
Cc: Ville Syrjälä 
Reviewed-by: Daniel Vetter 
Signed-off-by: Lyude 
---
 drivers/gpu/drm/i915/i915_drv.c |  3 ++
 drivers/gpu/drm/i915/i915_drv.h |  3 ++
 drivers/gpu/drm/i915/intel_drv.h|  2 +
 drivers/gpu/drm/i915/intel_hotplug.c| 90 -
 drivers/gpu/drm/i915/intel_runtime_pm.c |  2 +
 5 files changed, 88 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 3eb47fb..86ff8a7 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1612,6 +1612,9 @@ static int intel_runtime_suspend(struct device *device)
 
assert_forcewakes_inactive(dev_priv);
 
+   if (!IS_VALLEYVIEW(dev_priv) || !IS_CHERRYVIEW(dev_priv))
+   intel_hpd_poll_init(dev_priv);
+
DRM_DEBUG_KMS("Device suspended\n");
return 0;
 }
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 239a3ec..bbcd625 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -283,6 +283,9 @@ struct i915_hotplug {
u32 short_port_mask;
struct work_struct dig_port_work;
 
+   struct work_struct poll_init_work;
+   bool poll_enabled;
+
/*
 * if we get a HPD irq from DP and a HPD irq from non-DP
 * the non-DP HPD could block the workqueue on a mode config
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index dcbfdde..8af0668 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1385,6 +1385,8 @@ int intel_dsi_dcs_init_backlight_funcs(struct 
intel_connector *intel_connector);
 
 /* intel_dvo.c */
 void intel_dvo_init(struct drm_device *dev);
+/* intel_hotplug.c */
+void intel_hpd_poll_init(struct drm_i915_private *dev_priv);
 
 
 /* legacy fbdev emulation in intel_fbdev.c */
diff --git a/drivers/gpu/drm/i915/intel_hotplug.c 
b/drivers/gpu/drm/i915/intel_hotplug.c
index ec3285f..816c761 100644
--- a/drivers/gpu/drm/i915/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/intel_hotplug.c
@@ -452,20 +452,47 @@ void intel_hpd_irq_handler(struct drm_i915_private 
*dev_priv,
  *
  * This is a separate step from interrupt enabling to simplify the locking 
rules
  * in the driver load and 

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[James Bottomley]

On Tue, 2016-06-21 at 18:44 +0300, Ville Syrjälä wrote:
> On Tue, Jun 21, 2016 at 09:53:15AM -0400, James Bottomley wrote:
> > On Mon, 2016-06-20 at 11:03 +0300, Jani Nikula wrote:
> > > Cc: Ville
> > > 
> > > On Mon, 20 Jun 2016, James Bottomley <
> > > james.bottom...@hansenpartnership.com> wrote:
> > > > OK, my candidate bad commit is this one:
> > > > 
> > > > commit a05628195a0d9f3173dd9aa76f482aef692e46ee
> > > > Author: Ville Syrjälä 
> > > > Date:   Mon Apr 11 10:23:51 2016 +0300
> > > > 
> > > > drm/i915: Get panel_type from OpRegion panel details
> > > > 
> > > > After being more careful about waiting to identify flicker, 
> > > > this one seems to be the one the bisect finds.  I'm now running 
> > > > v4.7-rc3 with this one reverted and am currently seeing no 
> > > > flicker problems.   It is, however, early days because the 
> > > > flicker can hide for long periods, so I 'll wait until Monday 
> > > > evening and a few reboots before declaring victory.
> > > 
> > > If that turns out to be the bad commit, it doesn't really 
> > > surprise me, and that in itself is depressing.
> > 
> > As far as I can tell, after running for a day with this reverted, 
> > this is the problem.  The flicker hasn't appeared with it reverted.
> >  It's pretty noticeable with this commit included.
> 
> Hmm. The only difference I can see is low vs. normal vswing. Panel 0 
> has low, panel 2 has normal. So either the VBT or opregion is telling
> utter lies, or there's some other bug in our low vswing support.
> 
> To confirm it's really a vswing issue, you should be able to run with
> i915.edp_vswing=2 without flickers on the broken kernel.

Preliminary boot indicates no flicker with the bad commit included and
this option, but I'll have to run for quite a bit longer to verify,
since it can sometimes be elusive.

James

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

[Intel-gfx] [PATCH v6 1/4] drm/i915/vlv: Make intel_crt_reset() per-encoder

[Lyude]

This lets call intel_crt_reset() in contexts where IRQs are disabled and
as such, can't hold the locks required to work with the connectors.

Cc: sta...@vger.kernel.org
Cc: Ville Syrjälä 
Acked-by: Daniel Vetter 
Signed-off-by: Lyude 
---
 drivers/gpu/drm/i915/intel_crt.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index e115bcc..dfcd718 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -713,11 +713,11 @@ static int intel_crt_set_property(struct drm_connector 
*connector,
return 0;
 }
 
-static void intel_crt_reset(struct drm_connector *connector)
+static void intel_crt_reset(struct drm_encoder *encoder)
 {
-   struct drm_device *dev = connector->dev;
+   struct drm_device *dev = encoder->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
-   struct intel_crt *crt = intel_attached_crt(connector);
+   struct intel_crt *crt = intel_encoder_to_crt(to_intel_encoder(encoder));
 
if (INTEL_INFO(dev)->gen >= 5) {
u32 adpa;
@@ -739,7 +739,6 @@ static void intel_crt_reset(struct drm_connector *connector)
  */
 
 static const struct drm_connector_funcs intel_crt_connector_funcs = {
-   .reset = intel_crt_reset,
.dpms = drm_atomic_helper_connector_dpms,
.detect = intel_crt_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
@@ -757,6 +756,7 @@ static const struct drm_connector_helper_funcs 
intel_crt_connector_helper_funcs
 };
 
 static const struct drm_encoder_funcs intel_crt_enc_funcs = {
+   .reset = intel_crt_reset,
.destroy = intel_encoder_destroy,
 };
 
@@ -901,5 +901,5 @@ void intel_crt_init(struct drm_device *dev)
dev_priv->fdi_rx_config = I915_READ(FDI_RX_CTL(PIPE_A)) & 
fdi_config;
}
 
-   intel_crt_reset(connector);
+   intel_crt_reset(>base.base);
 }
-- 
2.5.5

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

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Use atomic commits for legacy page_flips

[Chris Wilson]

On Tue, Jun 21, 2016 at 04:23:42PM +0200, Daniel Vetter wrote:
> Adding Maarten/Daniela since I'm going on vacation.
> -Daniel
> 
> On Mon, Jun 20, 2016 at 8:30 PM, Matthew Auld
>  wrote:
> > I seem to be hitting some issues with this, at least in gnome-shell
> > which I bisected to this commit. Somewhat hard to describe but the
> > background window or desktop is partiality and intermittently drawn,
> > almost like a flicker onto the foreground window, title-bar etc.
> > typically during any kind of transition animation, like switching
> > windows, though sometimes just at random. Any ideas, I take it you
> > haven't seen anything like this while testing?

The effect is that we are either rendering onto the current scanout or
the next scanout is being presented with rendering unflushed.
Probably the former. Underruns have been known to have similar flicker
(at least on bdw+) but this feels more like rendering to the wrong
buffer.
-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 driver/intel] sna/cursor: Make sure hw cursors are disabled before disabling secondary planes

[Chris Wilson]

On Tue, Jun 21, 2016 at 07:34:34PM +0200, Egbert Eich wrote:
> When the hw cursors are not disabled before the cursor planes get disabled
> we may lose the cursor later on. Thus make sure the cursors are disabled
> before the cursor planes are.

The cursor would already be controlled by the xf86SetDesiredModes(), so
we can skip disabling entirely. What we should do instead is add the
paranoia check, but I can't see an easy way to inquire what the kernel
thinks the legacy cursor handle should be.

commit f1c757e4518f6835bbff6c940269a5c6be75f202
Author: Chris Wilson 
Date:   Tue Jun 21 21:17:15 2016 +0100

sna: Only shutdown unknown secondary planes on CRTC we control

In a ZaphodHead scenario, we do not own all the CRTC and so we should
not be making changes outside of our zone of control. Also, we only want
to disable secondary overlay planes and ignore the secondary cursor
planes which are controlled through the normal modesetting.

As we are now tracking all sprite planes on a CRTC, this leads to much
simpler code.

Reported-by: Egbert Eich 
Signed-off-by: Chris Wilson 
-Chris


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

Re: [Intel-gfx] [PATCH v4 4/4] drm/i915: Enable polling when we don't have hpd

[Daniel Vetter]

On Tue, Jun 21, 2016 at 02:18:35PM -0400, Lyude wrote:
> Unfortunately, there's two situations where we lose hpd right now:
> - Runtime suspend
> - When we've shut off all of the power wells on Valleyview/Cherryview
> 
> While it would be nice if this didn't cause issues, this has the
> ability to get us in some awkward states where a user won't be able to
> get their display to turn on. For instance; if we boot a Valleyview
> system without any monitors connected, it won't need any of it's power
> wells and thus shut them off. Since this causes us to lose HPD, this
> means that unless the user knows how to ssh into their machine and do a
> manual reprobe for monitors, none of the monitors they connect after
> booting will actually work.
> 
> Eventually we should come up with a better fix then having to enable
> polling for this, since this makes rpm a lot less useful, but for now
> the infrastructure in i915 just isn't there yet to get hpd in these
> situations.
> 
> Changes since v1:
>  - Add comment explaining the addition of the if
>(!mode_config->poll_running) in intel_hpd_init()
>  - Remove unneeded if (!dev->mode_config.poll_enabled) in
>i915_hpd_poll_init_work()
>  - Call to drm_helper_hpd_irq_event() after we disable polling
>  - Add cancel_work_sync() call to intel_hpd_cancel_work()
> 
> Changes since v2:
>  - Apparently dev->mode_config.poll_running doesn't actually reflect
>whether or not a poll is currently in progress, and is actually used
>for dynamic module paramter enabling/disabling. So now we instead
>keep track of our own poll_running variable in dev_priv->hotplug
>  - Clean i915_hpd_poll_init_work() a little bit
> 
> Changes since v3:
>  - Remove the now-redundant connector loop in intel_hpd_init(), just
>rely on intel_hpd_poll_enable() for setting connector->polled
>correctly on each connector
>  - Get rid of poll_running
>  - Don't assign enabled in i915_hpd_poll_init_work before we actually
>lock dev->mode_config.mutex
>  - Wrap enabled assignment in i915_hpd_poll_init_work() in READ_ONCE()
>for doc purposes
>  - Do the same for dev_priv->hotplug.poll_enabled with WRITE_ONCE in
>intel_hpd_poll_enable()
>  - Add some comments about racing not mattering in intel_hpd_poll_enable
> 
> Cc: sta...@vger.kernel.org
> Cc: Ville Syrjälä 
> Cc: Daniel Vetter 
> Signed-off-by: Lyude 
> ---
>  drivers/gpu/drm/i915/i915_drv.c |  7 ++-
>  drivers/gpu/drm/i915/i915_drv.h |  3 ++
>  drivers/gpu/drm/i915/intel_drv.h|  2 +
>  drivers/gpu/drm/i915/intel_hotplug.c| 76 
> ++---
>  drivers/gpu/drm/i915/intel_runtime_pm.c |  3 ++
>  5 files changed, 75 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 3eb47fb..5381d9e 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1612,6 +1612,9 @@ static int intel_runtime_suspend(struct device *device)
>  
>   assert_forcewakes_inactive(dev_priv);
>  
> + if (!IS_VALLEYVIEW(dev_priv) || !IS_CHERRYVIEW(dev_priv))
> + intel_hpd_poll_enable(dev_priv, true);
> +
>   DRM_DEBUG_KMS("Device suspended\n");
>   return 0;
>  }
> @@ -1667,8 +1670,10 @@ static int intel_runtime_resume(struct device *device)
>* power well, so hpd is reinitialized from there. For
>* everyone else do it here.
>*/
> - if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv))
> + if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv)) {
>   intel_hpd_init(dev_priv);
> + intel_hpd_poll_enable(dev_priv, false);
> + }
>  
>   intel_enable_gt_powersave(dev_priv);
>  
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 239a3ec..944c0d0 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -283,6 +283,9 @@ struct i915_hotplug {
>   u32 short_port_mask;
>   struct work_struct dig_port_work;
>  
> + struct work_struct poll_enable_work;
> + bool poll_enabled;
> +
>   /*
>* if we get a HPD irq from DP and a HPD irq from non-DP
>* the non-DP HPD could block the workqueue on a mode config
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index dcbfdde..cedac13 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1385,6 +1385,8 @@ int intel_dsi_dcs_init_backlight_funcs(struct 
> intel_connector *intel_connector);
>  
>  /* intel_dvo.c */
>  void intel_dvo_init(struct drm_device *dev);
> +/* intel_hotplug.c */
> +void intel_hpd_poll_enable(struct drm_i915_private *dev_priv, bool enabled);
>  
>  
>  /* legacy fbdev emulation in intel_fbdev.c */
> diff --git a/drivers/gpu/drm/i915/intel_hotplug.c 
> b/drivers/gpu/drm/i915/intel_hotplug.c
> index 

Re: [Intel-gfx] [PATCH 01/10] drm/amd-kfd: Clean up inline handling

[Daniel Vetter]

On Tue, Jun 21, 2016 at 10:11:13PM +0300, Oded Gabbay wrote:
> On Tue, Jun 21, 2016 at 12:10 PM, Daniel Vetter  
> wrote:
> > - inline functions need to be static inline, otherwise gcc can opt to
> >   not inline and the linker gets unhappy.
> > - no forward decls for inline functions, just include the right headers.
> >
> > Cc: Oded Gabbay 
> > Cc: Ben Goz 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h | 4 ++--
> >  drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 3 ---
> >  2 files changed, 2 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h 
> > b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h
> > index ec4036a09f3e..a625b9137da2 100644
> > --- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h
> > +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h
> > @@ -187,12 +187,12 @@ int init_pipelines(struct device_queue_manager *dqm,
> >  unsigned int get_first_pipe(struct device_queue_manager *dqm);
> >  unsigned int get_pipes_num(struct device_queue_manager *dqm);
> >
> > -extern inline unsigned int get_sh_mem_bases_32(struct kfd_process_device 
> > *pdd)
> > +static inline unsigned int get_sh_mem_bases_32(struct kfd_process_device 
> > *pdd)
> >  {
> > return (pdd->lds_base >> 16) & 0xFF;
> >  }
> >
> > -extern inline unsigned int
> > +static inline unsigned int
> >  get_sh_mem_bases_nybble_64(struct kfd_process_device *pdd)
> >  {
> > return (pdd->lds_base >> 60) & 0x0E;
> > diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h 
> > b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
> > index d0d5f4baf72d..80113c335966 100644
> > --- a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
> > +++ b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
> > @@ -617,10 +617,7 @@ int kgd2kfd_resume(struct kfd_dev *kfd);
> >  int kfd_init_apertures(struct kfd_process *process);
> >
> >  /* Queue Context Management */
> > -inline uint32_t lower_32(uint64_t x);
> > -inline uint32_t upper_32(uint64_t x);
> >  struct cik_sdma_rlc_registers *get_sdma_mqd(void *mqd);
> > -inline uint32_t get_sdma_base_addr(struct cik_sdma_rlc_registers *m);
> >
> >  int init_queue(struct queue **q, struct queue_properties properties);
> >  void uninit_queue(struct queue *q);
> > --
> > 2.8.1
> >
> 
> Hi Daniel,
> Minor comment, please change the commit message title to "drm/amdkfd:
> ..." (without the "-" between amd and kfd), to make this patch
> consistent with all amdkfd patches.
> 
> With that change, this patch is:
> Reviewed-by: Oded Gabbay 

Fixed up an applied to drm-misc, thanks for the review.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 01/10] drm/amd-kfd: Clean up inline handling

[Oded Gabbay]

On Tue, Jun 21, 2016 at 12:10 PM, Daniel Vetter  wrote:
> - inline functions need to be static inline, otherwise gcc can opt to
>   not inline and the linker gets unhappy.
> - no forward decls for inline functions, just include the right headers.
>
> Cc: Oded Gabbay 
> Cc: Ben Goz 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h | 4 ++--
>  drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 3 ---
>  2 files changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h 
> b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h
> index ec4036a09f3e..a625b9137da2 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.h
> @@ -187,12 +187,12 @@ int init_pipelines(struct device_queue_manager *dqm,
>  unsigned int get_first_pipe(struct device_queue_manager *dqm);
>  unsigned int get_pipes_num(struct device_queue_manager *dqm);
>
> -extern inline unsigned int get_sh_mem_bases_32(struct kfd_process_device 
> *pdd)
> +static inline unsigned int get_sh_mem_bases_32(struct kfd_process_device 
> *pdd)
>  {
> return (pdd->lds_base >> 16) & 0xFF;
>  }
>
> -extern inline unsigned int
> +static inline unsigned int
>  get_sh_mem_bases_nybble_64(struct kfd_process_device *pdd)
>  {
> return (pdd->lds_base >> 60) & 0x0E;
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h 
> b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
> index d0d5f4baf72d..80113c335966 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
> @@ -617,10 +617,7 @@ int kgd2kfd_resume(struct kfd_dev *kfd);
>  int kfd_init_apertures(struct kfd_process *process);
>
>  /* Queue Context Management */
> -inline uint32_t lower_32(uint64_t x);
> -inline uint32_t upper_32(uint64_t x);
>  struct cik_sdma_rlc_registers *get_sdma_mqd(void *mqd);
> -inline uint32_t get_sdma_base_addr(struct cik_sdma_rlc_registers *m);
>
>  int init_queue(struct queue **q, struct queue_properties properties);
>  void uninit_queue(struct queue *q);
> --
> 2.8.1
>

Hi Daniel,
Minor comment, please change the commit message title to "drm/amdkfd:
..." (without the "-" between amd and kfd), to make this patch
consistent with all amdkfd patches.

With that change, this patch is:
Reviewed-by: Oded Gabbay 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Vivi, Rodrigo]

Hi Peter,

On Tue, 2016-06-21 at 19:11 +0100, Peter Antoine wrote:
> This patch adds the HuC Loading for the BXT.
> Version 1.x of the HuC firmware.
> 
> Signed-off-by: Peter Antoine 
> ---
>  drivers/gpu/drm/i915/i915_gem.c | 13 +++--
>  drivers/gpu/drm/i915/intel_guc_loader.c | 29 +
> 
>  drivers/gpu/drm/i915/intel_huc_loader.c |  7 +++
>  3 files changed, 27 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c
> b/drivers/gpu/drm/i915/i915_gem.c
> index 549dd3f..6abd5e5 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -5143,16 +5143,9 @@ i915_gem_init_hw(struct drm_device *dev)
>   intel_mocs_init_l3cc_table(dev);
>  
>   /* We can't enable contexts until all firmware is loaded */
> - if (HAS_GUC(dev)) {
> - /* init WOPCM */
> - I915_WRITE(GUC_WOPCM_SIZE, guc_wopcm_size(dev));
> - I915_WRITE(DMA_GUC_WOPCM_OFFSET,
> GUC_WOPCM_OFFSET_VALUE);
> -
> - intel_huc_load(dev);
> - ret = intel_guc_setup(dev);
> - if (ret)
> - goto out;
> - }
> + ret = intel_guc_setup(dev);
> + if (ret)
> + goto out;
>  
>   /*
>    * Increment the next seqno by 0x100 so we have a visible
> break
> diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
> b/drivers/gpu/drm/i915/intel_guc_loader.c
> index e876a23f..289b5b6 100644
> --- a/drivers/gpu/drm/i915/intel_guc_loader.c
> +++ b/drivers/gpu/drm/i915/intel_guc_loader.c
> @@ -82,6 +82,17 @@ const char *intel_uc_fw_status_repr(enum
> intel_uc_fw_status status)
>   }
>  };
>  
> +u32 guc_wopcm_size(struct drm_device *dev)
> +{
> + u32 wopcm_size = GUC_WOPCM_TOP;
> +
> + /* On BXT, the top of WOPCM is reserved for RC6 context */
> + if (IS_BROXTON(dev))
> + wopcm_size -= BXT_GUC_WOPCM_RC6_RESERVED;
> +
> + return wopcm_size;
> +}
> +
>  static void direct_interrupts_to_host(struct drm_i915_private
> *dev_priv)
>  {
>   struct intel_engine_cs *engine;
> @@ -296,17 +307,6 @@ static int guc_ucode_xfer_dma(struct
> drm_i915_private *dev_priv)
>   return ret;
>  }
>  
> -u32 guc_wopcm_size(struct drm_device *dev)
> -{
> - u32 wopcm_size = GUC_WOPCM_TOP;
> -
> - /* On BXT, the top of WOPCM is reserved for RC6 context */
> - if (IS_BROXTON(dev))
> - wopcm_size -= BXT_GUC_WOPCM_RC6_RESERVED;
> -
> - return wopcm_size;
> -}
> -
>  /*
>   * Load the GuC firmware blob into the MinuteIA.
>   */
> @@ -333,6 +333,10 @@ static int guc_ucode_xfer(struct
> drm_i915_private *dev_priv)
>  
>   intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
>  
> + /* init WOPCM */
> + I915_WRITE(GUC_WOPCM_SIZE, guc_wopcm_size(dev));
> + I915_WRITE(DMA_GUC_WOPCM_OFFSET, GUC_WOPCM_OFFSET_VALUE);
> +
>   /* Enable MIA caching. GuC clock gating is disabled. */
>   I915_WRITE(GUC_SHIM_CONTROL, GUC_SHIM_CONTROL_VALUE);
>  
> @@ -483,6 +487,7 @@ int intel_guc_setup(struct drm_device *dev)
>   goto fail;
>   }
>  
> + intel_huc_load(dev);
>   err = guc_ucode_xfer(dev_priv);
>   if (!err)
>   break;
> @@ -638,7 +643,7 @@ void intel_uc_fw_fetch(struct drm_device *dev,
> struct intel_uc_fw *uc_fw)
>   size = uc_fw->header_size + uc_fw->ucode_size;
>  
>   /* Top 32k of WOPCM is reserved (8K stack + 24k RC6
> context). */
> - if (size > guc_wopcm_size(dev->dev_private)) {
> + if (size > guc_wopcm_size(dev)) {
>   DRM_ERROR("Firmware is too large to fit in
> WOPCM\n");
>   goto fail;
>   }
> diff --git a/drivers/gpu/drm/i915/intel_huc_loader.c
> b/drivers/gpu/drm/i915/intel_huc_loader.c
> index 7205e9e..7a43d4e 100644
> --- a/drivers/gpu/drm/i915/intel_huc_loader.c
> +++ b/drivers/gpu/drm/i915/intel_huc_loader.c
> @@ -49,6 +49,9 @@
>  #define I915_SKL_HUC_UCODE "i915/skl_huc_ver1.bin"
>  MODULE_FIRMWARE(I915_SKL_HUC_UCODE);

We need to step away from symbolic links for all firmwares.

Specially with HuC that HuC team had never agreed with major_minor
where major increases if any change in API or ABI.

And also they have the major_minor_build number in the release like

intel/firmware/skl_huc_ver01_07_1398

So I believe we need to fix this first and then add the BXT in the
proper way without using any symbolic link.

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

Also, where is this version? I believe I missed this release while I
was out. Could you please share with me?

Is it production and with all permissions to release at 01.org and
propagate to linux-firmware.git?

Thanks,
Rodrigo.

> +
>  /**
>   * intel_huc_load_ucode() - DMA's the firmware
>   * @dev: the drm device
> @@ -157,6 +160,10 @@ void intel_huc_init(struct 

[Intel-gfx] [PATCH v4 4/4] drm/i915: Enable polling when we don't have hpd

[Lyude]

Unfortunately, there's two situations where we lose hpd right now:
- Runtime suspend
- When we've shut off all of the power wells on Valleyview/Cherryview

While it would be nice if this didn't cause issues, this has the
ability to get us in some awkward states where a user won't be able to
get their display to turn on. For instance; if we boot a Valleyview
system without any monitors connected, it won't need any of it's power
wells and thus shut them off. Since this causes us to lose HPD, this
means that unless the user knows how to ssh into their machine and do a
manual reprobe for monitors, none of the monitors they connect after
booting will actually work.

Eventually we should come up with a better fix then having to enable
polling for this, since this makes rpm a lot less useful, but for now
the infrastructure in i915 just isn't there yet to get hpd in these
situations.

Changes since v1:
 - Add comment explaining the addition of the if
   (!mode_config->poll_running) in intel_hpd_init()
 - Remove unneeded if (!dev->mode_config.poll_enabled) in
   i915_hpd_poll_init_work()
 - Call to drm_helper_hpd_irq_event() after we disable polling
 - Add cancel_work_sync() call to intel_hpd_cancel_work()

Changes since v2:
 - Apparently dev->mode_config.poll_running doesn't actually reflect
   whether or not a poll is currently in progress, and is actually used
   for dynamic module paramter enabling/disabling. So now we instead
   keep track of our own poll_running variable in dev_priv->hotplug
 - Clean i915_hpd_poll_init_work() a little bit

Changes since v3:
 - Remove the now-redundant connector loop in intel_hpd_init(), just
   rely on intel_hpd_poll_enable() for setting connector->polled
   correctly on each connector
 - Get rid of poll_running
 - Don't assign enabled in i915_hpd_poll_init_work before we actually
   lock dev->mode_config.mutex
 - Wrap enabled assignment in i915_hpd_poll_init_work() in READ_ONCE()
   for doc purposes
 - Do the same for dev_priv->hotplug.poll_enabled with WRITE_ONCE in
   intel_hpd_poll_enable()
 - Add some comments about racing not mattering in intel_hpd_poll_enable

Cc: sta...@vger.kernel.org
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Signed-off-by: Lyude 
---
 drivers/gpu/drm/i915/i915_drv.c |  7 ++-
 drivers/gpu/drm/i915/i915_drv.h |  3 ++
 drivers/gpu/drm/i915/intel_drv.h|  2 +
 drivers/gpu/drm/i915/intel_hotplug.c| 76 ++---
 drivers/gpu/drm/i915/intel_runtime_pm.c |  3 ++
 5 files changed, 75 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 3eb47fb..5381d9e 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1612,6 +1612,9 @@ static int intel_runtime_suspend(struct device *device)
 
assert_forcewakes_inactive(dev_priv);
 
+   if (!IS_VALLEYVIEW(dev_priv) || !IS_CHERRYVIEW(dev_priv))
+   intel_hpd_poll_enable(dev_priv, true);
+
DRM_DEBUG_KMS("Device suspended\n");
return 0;
 }
@@ -1667,8 +1670,10 @@ static int intel_runtime_resume(struct device *device)
 * power well, so hpd is reinitialized from there. For
 * everyone else do it here.
 */
-   if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv))
+   if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv)) {
intel_hpd_init(dev_priv);
+   intel_hpd_poll_enable(dev_priv, false);
+   }
 
intel_enable_gt_powersave(dev_priv);
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 239a3ec..944c0d0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -283,6 +283,9 @@ struct i915_hotplug {
u32 short_port_mask;
struct work_struct dig_port_work;
 
+   struct work_struct poll_enable_work;
+   bool poll_enabled;
+
/*
 * if we get a HPD irq from DP and a HPD irq from non-DP
 * the non-DP HPD could block the workqueue on a mode config
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index dcbfdde..cedac13 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1385,6 +1385,8 @@ int intel_dsi_dcs_init_backlight_funcs(struct 
intel_connector *intel_connector);
 
 /* intel_dvo.c */
 void intel_dvo_init(struct drm_device *dev);
+/* intel_hotplug.c */
+void intel_hpd_poll_enable(struct drm_i915_private *dev_priv, bool enabled);
 
 
 /* legacy fbdev emulation in intel_fbdev.c */
diff --git a/drivers/gpu/drm/i915/intel_hotplug.c 
b/drivers/gpu/drm/i915/intel_hotplug.c
index ec3285f..f23330d 100644
--- a/drivers/gpu/drm/i915/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/intel_hotplug.c
@@ -455,28 +455,14 @@ void intel_hpd_irq_handler(struct drm_i915_private 
*dev_priv,
  */
 void intel_hpd_init(struct drm_i915_private *dev_priv)
 {
- 

[Intel-gfx] [PATCH 5/6] drm/i915/huc: Support HuC authentication

[Peter Antoine]

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

Signed-off-by: Alex Dai 
Signed-off-by: Peter Antoine 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 65 ++
 drivers/gpu/drm/i915/intel_guc_fwif.h  |  1 +
 drivers/gpu/drm/i915/intel_guc_loader.c|  2 +
 drivers/gpu/drm/i915/intel_huc_loader.c|  5 +++
 4 files changed, 73 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index bfb8400..41f3a42 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -25,6 +25,7 @@
 #include 
 #include "i915_drv.h"
 #include "intel_guc.h"
+#include "intel_huc.h"
 
 /**
  * DOC: GuC-based command submission
@@ -1077,3 +1078,67 @@ int intel_guc_resume(struct drm_device *dev)
 
return host2guc_action(guc, data, ARRAY_SIZE(data));
 }
+
+/**
+ * intel_huc_auth() - authenticate ucode
+ * @dev: the drm device
+ *
+ * Triggers a HuC fw authentication request to the GuC via host-2-guc
+ * interface.
+ */
+void intel_huc_auth(struct drm_device *dev)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct intel_guc *guc = _priv->guc;
+   struct intel_huc *huc = _priv->huc;
+   int ret;
+   u32 data[2];
+
+   /* Bypass the case where there is no HuC firmware */
+   if (huc->huc_fw.fetch_status == UC_FIRMWARE_NONE ||
+   huc->huc_fw.load_status == UC_FIRMWARE_NONE)
+   return;
+
+   if (guc->guc_fw.load_status != UC_FIRMWARE_SUCCESS) {
+   DRM_ERROR("HuC: GuC fw wasn't loaded. Can't authenticate");
+   return;
+   }
+
+   if (huc->huc_fw.load_status != UC_FIRMWARE_SUCCESS) {
+   DRM_ERROR("HuC: fw wasn't loaded. Nothing to authenticate");
+   return;
+   }
+
+   ret = i915_gem_obj_ggtt_pin(huc->huc_fw.uc_fw_obj, 0, 0);
+   if (ret) {
+   DRM_ERROR("HuC: Pin failed");
+   return;
+   }
+
+   /* Invalidate GuC TLB to let GuC take the latest updates to GTT. */
+   I915_WRITE(GEN8_GTCR, GEN8_GTCR_INVALIDATE);
+
+   /* Specify auth action and where public signature is. It's stored
+* at the beginning of the gem object, before the fw bits
+*/
+   data[0] = HOST2GUC_ACTION_AUTHENTICATE_HUC;
+   data[1] = i915_gem_obj_ggtt_offset(huc->huc_fw.uc_fw_obj) +
+   huc->huc_fw.rsa_offset;
+
+   ret = host2guc_action(guc, data, ARRAY_SIZE(data));
+   if (ret) {
+   DRM_ERROR("HuC: GuC did not ack Auth request\n");
+   goto out;
+   }
+
+   /* Check authentication status, it should be done by now */
+   ret = wait_for_atomic(
+   (I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED) > 0, 50);
+   if (ret) {
+   DRM_ERROR("HuC: Authentication failed\n");
+   goto out;
+   }
+
+out:
+   i915_gem_object_ggtt_unpin(huc->huc_fw.uc_fw_obj);
+}
diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/intel_guc_fwif.h
index a69ee36..c5a6227 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
@@ -437,6 +437,7 @@ enum host2guc_action {
HOST2GUC_ACTION_ENTER_S_STATE = 0x501,
HOST2GUC_ACTION_EXIT_S_STATE = 0x502,
HOST2GUC_ACTION_SLPC_REQUEST = 0x3003,
+   HOST2GUC_ACTION_AUTHENTICATE_HUC = 0x4000,
HOST2GUC_ACTION_LIMIT
 };
 
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index c4a210d..e876a23f 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -500,6 +500,8 @@ int intel_guc_setup(struct drm_device *dev)
intel_uc_fw_status_repr(guc_fw->fetch_status),
intel_uc_fw_status_repr(guc_fw->load_status));
 
+   intel_huc_auth(dev);
+
if (i915.enable_guc_submission) {
err = i915_guc_submission_enable(dev_priv);
if (err)
diff --git a/drivers/gpu/drm/i915/intel_huc_loader.c 
b/drivers/gpu/drm/i915/intel_huc_loader.c
index 472fabe..7205e9e 100644
--- a/drivers/gpu/drm/i915/intel_huc_loader.c
+++ b/drivers/gpu/drm/i915/intel_huc_loader.c
@@ -86,6 +86,11 @@ static int huc_ucode_xfer(struct drm_i915_private *dev_priv)
WARN_ON(!mutex_is_locked(_priv->dev->struct_mutex));
intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
 
+   /* init WOPCM */
+   I915_WRITE(GUC_WOPCM_SIZE, guc_wopcm_size(dev_priv->dev));
+   I915_WRITE(DMA_GUC_WOPCM_OFFSET, GUC_WOPCM_OFFSET_VALUE |
+   HUC_LOADING_AGENT_GUC);
+
/* Set the source address for the uCode */
offset = i915_gem_obj_ggtt_offset(huc_fw->uc_fw_obj) +
huc_fw->header_offset;
-- 
1.9.1

___

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

[Peter Antoine]

From: Alex Dai 

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

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

Signed-off-by: Alex Dai 
Signed-off-by: Peter Antoine 
---
 drivers/gpu/drm/i915/Makefile   |   1 +
 drivers/gpu/drm/i915/i915_dma.c |   3 +
 drivers/gpu/drm/i915/i915_drv.h |   3 +
 drivers/gpu/drm/i915/i915_gem.c |  13 +-
 drivers/gpu/drm/i915/i915_guc_reg.h |   3 +
 drivers/gpu/drm/i915/intel_guc.h|   1 +
 drivers/gpu/drm/i915/intel_guc_loader.c |  11 +-
 drivers/gpu/drm/i915/intel_huc.h|  44 ++
 drivers/gpu/drm/i915/intel_huc_loader.c | 262 
 9 files changed, 331 insertions(+), 10 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_huc.h
 create mode 100644 drivers/gpu/drm/i915/intel_huc_loader.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 276abf1..7384db0 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -44,6 +44,7 @@ i915-y += i915_cmd_parser.o \
 
 # general-purpose microcontroller (GuC) support
 i915-y += intel_guc_loader.o \
+ intel_huc_loader.o \
  i915_guc_submission.o
 
 # autogenerated null render state
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index e28c0dd..a449a59 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -507,6 +507,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
 * working irqs for e.g. gmbus and dp aux transfers. */
intel_modeset_init(dev);
 
+   intel_huc_init(dev);
intel_guc_init(dev);
 
ret = i915_gem_init(dev);
@@ -532,6 +533,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
 cleanup_gem:
i915_gem_fini(dev);
 cleanup_irq:
+   intel_huc_fini(dev);
intel_guc_fini(dev);
drm_irq_uninstall(dev);
intel_teardown_gmbus(dev);
@@ -1563,6 +1565,7 @@ int i915_driver_unload(struct drm_device *dev)
/* Flush any outstanding unpin_work. */
flush_workqueue(dev_priv->wq);
 
+   intel_huc_fini(dev);
intel_guc_fini(dev);
i915_gem_fini(dev);
intel_fbc_cleanup_cfb(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7c81757..8b88227 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -54,6 +54,7 @@
 #include "intel_bios.h"
 #include "intel_dpll_mgr.h"
 #include "intel_guc.h"
+#include "intel_huc.h"
 #include "intel_lrc.h"
 #include "intel_ringbuffer.h"
 
@@ -1749,6 +1750,7 @@ struct drm_i915_private {
 
struct intel_gvt gvt;
 
+   struct intel_huc huc;
struct intel_guc guc;
 
struct intel_csr csr;
@@ -2841,6 +2843,7 @@ struct drm_i915_cmd_table {
 #define HAS_GUC(dev)   (IS_GEN9(dev) && !IS_KABYLAKE(dev))
 #define HAS_GUC_UCODE(dev) (HAS_GUC(dev))
 #define HAS_GUC_SCHED(dev) (HAS_GUC(dev))
+#define HAS_HUC_UCODE(dev) (HAS_GUC(dev))
 
 #define HAS_RESOURCE_STREAMER(dev) (IS_HASWELL(dev) || \
INTEL_INFO(dev)->gen >= 8)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 6abd5e5..549dd3f 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5143,9 +5143,16 @@ i915_gem_init_hw(struct drm_device *dev)
intel_mocs_init_l3cc_table(dev);
 
/* We can't enable contexts until all firmware is loaded */
-   ret = intel_guc_setup(dev);
-   if (ret)
-   goto out;
+   if (HAS_GUC(dev)) {
+   /* init WOPCM */
+   I915_WRITE(GUC_WOPCM_SIZE, guc_wopcm_size(dev));
+   I915_WRITE(DMA_GUC_WOPCM_OFFSET, GUC_WOPCM_OFFSET_VALUE);
+
+   intel_huc_load(dev);
+   ret = intel_guc_setup(dev);
+   if (ret)
+   goto out;
+   }
 
/*
 * Increment the next seqno by 0x100 so we have a visible break
diff --git a/drivers/gpu/drm/i915/i915_guc_reg.h 
b/drivers/gpu/drm/i915/i915_guc_reg.h
index cf5a65b..51533f1 100644
--- a/drivers/gpu/drm/i915/i915_guc_reg.h
+++ b/drivers/gpu/drm/i915/i915_guc_reg.h
@@ -61,9 +61,12 @@
 #define   DMA_ADDRESS_SPACE_GTT  (8 << 16)
 #define DMA_COPY_SIZE  _MMIO(0xc310)
 #define DMA_CTRL   _MMIO(0xc314)
+#define   HUC_UKERNEL(1<<9)
 #define   UOS_MOVE   (1<<4)
 #define   START_DMA  (1<<0)
 #define DMA_GUC_WOPCM_OFFSET   _MMIO(0xc340)
+#define   HUC_LOADING_AGENT_VCR  (0<<1)
+#define   HUC_LOADING_AGENT_GUC  (1<<1)
 #define   GUC_WOPCM_OFFSET_VALUE 0x8   /* 512KB */
 #define GUC_MAX_IDLE_COUNT 

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

[Peter Antoine]

From: Alex Dai 

Add debugfs entry for HuC loading status check.

Signed-off-by: Alex Dai 
Signed-off-by: Peter Antoine 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 32 
 1 file changed, 32 insertions(+)

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

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

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

[Peter Antoine]

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

Signed-off-by: Peter Antoine 
---
 drivers/gpu/drm/i915/i915_gem.c | 13 +++--
 drivers/gpu/drm/i915/intel_guc_loader.c | 29 +
 drivers/gpu/drm/i915/intel_huc_loader.c |  7 +++
 3 files changed, 27 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 549dd3f..6abd5e5 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5143,16 +5143,9 @@ i915_gem_init_hw(struct drm_device *dev)
intel_mocs_init_l3cc_table(dev);
 
/* We can't enable contexts until all firmware is loaded */
-   if (HAS_GUC(dev)) {
-   /* init WOPCM */
-   I915_WRITE(GUC_WOPCM_SIZE, guc_wopcm_size(dev));
-   I915_WRITE(DMA_GUC_WOPCM_OFFSET, GUC_WOPCM_OFFSET_VALUE);
-
-   intel_huc_load(dev);
-   ret = intel_guc_setup(dev);
-   if (ret)
-   goto out;
-   }
+   ret = intel_guc_setup(dev);
+   if (ret)
+   goto out;
 
/*
 * Increment the next seqno by 0x100 so we have a visible break
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index e876a23f..289b5b6 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -82,6 +82,17 @@ const char *intel_uc_fw_status_repr(enum intel_uc_fw_status 
status)
}
 };
 
+u32 guc_wopcm_size(struct drm_device *dev)
+{
+   u32 wopcm_size = GUC_WOPCM_TOP;
+
+   /* On BXT, the top of WOPCM is reserved for RC6 context */
+   if (IS_BROXTON(dev))
+   wopcm_size -= BXT_GUC_WOPCM_RC6_RESERVED;
+
+   return wopcm_size;
+}
+
 static void direct_interrupts_to_host(struct drm_i915_private *dev_priv)
 {
struct intel_engine_cs *engine;
@@ -296,17 +307,6 @@ static int guc_ucode_xfer_dma(struct drm_i915_private 
*dev_priv)
return ret;
 }
 
-u32 guc_wopcm_size(struct drm_device *dev)
-{
-   u32 wopcm_size = GUC_WOPCM_TOP;
-
-   /* On BXT, the top of WOPCM is reserved for RC6 context */
-   if (IS_BROXTON(dev))
-   wopcm_size -= BXT_GUC_WOPCM_RC6_RESERVED;
-
-   return wopcm_size;
-}
-
 /*
  * Load the GuC firmware blob into the MinuteIA.
  */
@@ -333,6 +333,10 @@ static int guc_ucode_xfer(struct drm_i915_private 
*dev_priv)
 
intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
 
+   /* init WOPCM */
+   I915_WRITE(GUC_WOPCM_SIZE, guc_wopcm_size(dev));
+   I915_WRITE(DMA_GUC_WOPCM_OFFSET, GUC_WOPCM_OFFSET_VALUE);
+
/* Enable MIA caching. GuC clock gating is disabled. */
I915_WRITE(GUC_SHIM_CONTROL, GUC_SHIM_CONTROL_VALUE);
 
@@ -483,6 +487,7 @@ int intel_guc_setup(struct drm_device *dev)
goto fail;
}
 
+   intel_huc_load(dev);
err = guc_ucode_xfer(dev_priv);
if (!err)
break;
@@ -638,7 +643,7 @@ void intel_uc_fw_fetch(struct drm_device *dev, struct 
intel_uc_fw *uc_fw)
size = uc_fw->header_size + uc_fw->ucode_size;
 
/* Top 32k of WOPCM is reserved (8K stack + 24k RC6 context). */
-   if (size > guc_wopcm_size(dev->dev_private)) {
+   if (size > guc_wopcm_size(dev)) {
DRM_ERROR("Firmware is too large to fit in WOPCM\n");
goto fail;
}
diff --git a/drivers/gpu/drm/i915/intel_huc_loader.c 
b/drivers/gpu/drm/i915/intel_huc_loader.c
index 7205e9e..7a43d4e 100644
--- a/drivers/gpu/drm/i915/intel_huc_loader.c
+++ b/drivers/gpu/drm/i915/intel_huc_loader.c
@@ -49,6 +49,9 @@
 #define I915_SKL_HUC_UCODE "i915/skl_huc_ver1.bin"
 MODULE_FIRMWARE(I915_SKL_HUC_UCODE);
 
+#define I915_BXT_HUC_UCODE "i915/bxt_huc_ver1.bin"
+MODULE_FIRMWARE(I915_BXT_HUC_UCODE);
+
 /**
  * intel_huc_load_ucode() - DMA's the firmware
  * @dev: the drm device
@@ -157,6 +160,10 @@ void intel_huc_init(struct drm_device *dev)
fw_path = I915_SKL_HUC_UCODE;
huc_fw->major_ver_wanted = 1;
huc_fw->minor_ver_wanted = 5;
+   } else if (IS_BROXTON(dev)) {
+   fw_path = I915_BXT_HUC_UCODE;
+   huc_fw->major_ver_wanted = 1;
+   huc_fw->minor_ver_wanted = 0;
}
 
if (fw_path == NULL)
-- 
1.9.1

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

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

[Peter Antoine]

From: Alex Dai 

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

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

diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 836420b..0b4ed88 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -97,6 +97,9 @@ enum intel_uc_fw_status {
UC_FIRMWARE_SUCCESS
 };
 
+#define UC_FW_TYPE_GUC 0
+#define UC_FW_TYPE_HUC 1
+
 /*
  * This structure encapsulates all the data needed during the process
  * of fetching, caching, and loading the firmware image into the GuC.
@@ -114,6 +117,7 @@ struct intel_uc_fw {
uint16_t major_ver_found;
uint16_t minor_ver_found;
 
+   uint32_t fw_type;
uint32_t header_size;
uint32_t header_offset;
uint32_t rsa_size;
diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h 
b/drivers/gpu/drm/i915/intel_guc_fwif.h
index 944786d..a69ee36 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
@@ -154,7 +154,7 @@
  * The GuC firmware layout looks like this:
  *
  * +---+
- * |guc_css_header |
+ * | uc_css_header |
  * | contains major/minor version  |
  * +---+
  * | uCode |
@@ -180,9 +180,16 @@
  * 3. Length info of each component can be found in header, in dwords.
  * 4. Modulus and exponent key are not required by driver. They may not appear
  * in fw. So driver will load a truncated firmware in this case.
+ *
+ * HuC firmware layout is same as GuC firmware.
+ *
+ * HuC firmware css header is different. However, the only difference is where
+ * the version information is saved. The uc_css_header is unified to support
+ * both. Driver should get HuC version from uc_css_header.huc_sw_version, while
+ * uc_css_header.guc_sw_version for GuC.
  */
 
-struct guc_css_header {
+struct uc_css_header {
uint32_t module_type;
/* header_size includes all non-uCode bits, including css_header, rsa
 * key, modulus key and exponent data. */
@@ -213,7 +220,10 @@ struct guc_css_header {
 
char username[8];
char buildnumber[12];
-   uint32_t device_id;
+   union {
+   uint32_t device_id;
+   uint32_t huc_sw_version;
+   };
uint32_t guc_sw_version;
uint32_t prod_preprod_fw;
uint32_t reserved[12];
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index ff054f5..70575bd 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -574,7 +574,7 @@ void intel_uc_fw_fetch(struct drm_device *dev, struct 
intel_uc_fw *uc_fw)
 {
struct drm_i915_gem_object *obj;
const struct firmware *fw;
-   struct guc_css_header *css;
+   struct uc_css_header *css;
size_t size;
int err;
 
@@ -591,19 +591,19 @@ void intel_uc_fw_fetch(struct drm_device *dev, struct 
intel_uc_fw *uc_fw)
uc_fw->uc_fw_path, fw);
 
/* Check the size of the blob before examining buffer contents */
-   if (fw->size < sizeof(struct guc_css_header)) {
+   if (fw->size < sizeof(struct uc_css_header)) {
DRM_ERROR("Firmware header is missing\n");
goto fail;
}
 
-   css = (struct guc_css_header *)fw->data;
+   css = (struct uc_css_header *)fw->data;
 
/* Firmware bits always start from header */
uc_fw->header_offset = 0;
uc_fw->header_size = (css->header_size_dw - css->modulus_size_dw -
css->key_size_dw - css->exponent_size_dw) * sizeof(u32);
 
-   if (uc_fw->header_size != sizeof(struct guc_css_header)) {
+   if (uc_fw->header_size != sizeof(struct uc_css_header)) {
DRM_ERROR("CSS header definition mismatch\n");
goto fail;
}
@@ -627,23 +627,35 @@ void intel_uc_fw_fetch(struct drm_device *dev, struct 
intel_uc_fw *uc_fw)
goto fail;
}
 
-   /* Header and uCode will be loaded to WOPCM. Size of the two. */
-   size = uc_fw->header_size + uc_fw->ucode_size;
-
-   /* Top 32k of WOPCM is reserved (8K stack + 24k RC6 context). */
-   if (size > guc_wopcm_size(dev->dev_private)) {
-   DRM_ERROR("Firmware is too large to fit in WOPCM\n");
-   goto fail;
-   }
-
/*
 

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

[Peter Antoine]

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

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

Signed-off-by: Alex Dai 
Signed-off-by: Peter Antoine 
---
 drivers/gpu/drm/i915/i915_debugfs.c|  12 +-
 drivers/gpu/drm/i915/i915_guc_submission.c |   4 +-
 drivers/gpu/drm/i915/intel_guc.h   |  39 ++---
 drivers/gpu/drm/i915/intel_guc_loader.c| 221 -
 4 files changed, 151 insertions(+), 125 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 7d63af0..69964c2 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2483,7 +2483,7 @@ static int i915_guc_load_status_info(struct seq_file *m, 
void *data)
 {
struct drm_info_node *node = m->private;
struct drm_i915_private *dev_priv = node->minor->dev->dev_private;
-   struct intel_guc_fw *guc_fw = _priv->guc.guc_fw;
+   struct intel_uc_fw *guc_fw = _priv->guc.guc_fw;
u32 tmp, i;
 
if (!HAS_GUC_UCODE(dev_priv))
@@ -2491,15 +2491,15 @@ static int i915_guc_load_status_info(struct seq_file 
*m, void *data)
 
seq_printf(m, "GuC firmware status:\n");
seq_printf(m, "\tpath: %s\n",
-   guc_fw->guc_fw_path);
+   guc_fw->uc_fw_path);
seq_printf(m, "\tfetch: %s\n",
-   intel_guc_fw_status_repr(guc_fw->guc_fw_fetch_status));
+   intel_uc_fw_status_repr(guc_fw->fetch_status));
seq_printf(m, "\tload: %s\n",
-   intel_guc_fw_status_repr(guc_fw->guc_fw_load_status));
+   intel_uc_fw_status_repr(guc_fw->load_status));
seq_printf(m, "\tversion wanted: %d.%d\n",
-   guc_fw->guc_fw_major_wanted, guc_fw->guc_fw_minor_wanted);
+   guc_fw->major_ver_wanted, guc_fw->minor_ver_wanted);
seq_printf(m, "\tversion found: %d.%d\n",
-   guc_fw->guc_fw_major_found, guc_fw->guc_fw_minor_found);
+   guc_fw->major_ver_found, guc_fw->minor_ver_found);
seq_printf(m, "\theader: offset is %d; size = %d\n",
guc_fw->header_offset, guc_fw->header_size);
seq_printf(m, "\tuCode: offset is %d; size = %d\n",
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 01c7cdf..bfb8400 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -1039,7 +1039,7 @@ int intel_guc_suspend(struct drm_device *dev)
struct i915_gem_context *ctx;
u32 data[3];
 
-   if (guc->guc_fw.guc_fw_load_status != GUC_FIRMWARE_SUCCESS)
+   if (guc->guc_fw.load_status != UC_FIRMWARE_SUCCESS)
return 0;
 
ctx = dev_priv->kernel_context;
@@ -1065,7 +1065,7 @@ int intel_guc_resume(struct drm_device *dev)
struct i915_gem_context *ctx;
u32 data[3];
 
-   if (guc->guc_fw.guc_fw_load_status != GUC_FIRMWARE_SUCCESS)
+   if (guc->guc_fw.load_status != UC_FIRMWARE_SUCCESS)
return 0;
 
ctx = dev_priv->kernel_context;
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 3e3e743..836420b 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -90,29 +90,29 @@ struct i915_guc_client {
uint64_t submissions[I915_NUM_ENGINES];
 };
 
-enum intel_guc_fw_status {
-   GUC_FIRMWARE_FAIL = -1,
-   GUC_FIRMWARE_NONE = 0,
-   GUC_FIRMWARE_PENDING,
-   GUC_FIRMWARE_SUCCESS
+enum intel_uc_fw_status {
+   UC_FIRMWARE_FAIL = -1,
+   UC_FIRMWARE_NONE = 0,
+   UC_FIRMWARE_PENDING,
+   UC_FIRMWARE_SUCCESS
 };
 
 /*
  * This structure encapsulates all the data needed during the process
  * of fetching, caching, and loading the firmware image into the GuC.
  */
-struct intel_guc_fw {
-   struct drm_device * guc_dev;
-   const char *guc_fw_path;
-   size_t  guc_fw_size;
-   struct drm_i915_gem_object *guc_fw_obj;
-   enum intel_guc_fw_statusguc_fw_fetch_status;
-   enum intel_guc_fw_statusguc_fw_load_status;
-
-   uint16_tguc_fw_major_wanted;
-   uint16_tguc_fw_minor_wanted;
-   uint16_tguc_fw_major_found;
-   uint16_tguc_fw_minor_found;
+struct intel_uc_fw {
+   struct drm_device *uc_dev;
+   const char *uc_fw_path;
+   size_t uc_fw_size;
+   struct drm_i915_gem_object *uc_fw_obj;
+   enum intel_uc_fw_status fetch_status;
+   enum intel_uc_fw_status load_status;
+
+   uint16_t 

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

[Peter Antoine]

This patch series enables the HuC loading. These patches are a port of the
patches that were created by Yu Dai (Alex) and have been ported to work with
the new GuC patches.

The series include a patch to enable the HuC on BXT. This is a separate patch
as the state of the BXT HuC firmware is still in flux, so the patch can be
dropped without delaying the series.

Alex Dai (3):
  drm/i915/huc: Unified css_header struct for GuC and HuC
  drm/i915/huc: Add HuC fw loading support
  drm/i915/huc: Add debugfs for HuC loading status check

Peter Antoine (3):
  drm/i915/guc: Make the GuC fw loading helper functions general
  drm/i915/huc: Support HuC authentication
  drm/i915/huc: Add BXT HuC Loading Support

 drivers/gpu/drm/i915/Makefile  |   1 +
 drivers/gpu/drm/i915/i915_debugfs.c|  44 -
 drivers/gpu/drm/i915/i915_dma.c|   3 +
 drivers/gpu/drm/i915/i915_drv.h|   3 +
 drivers/gpu/drm/i915/i915_guc_reg.h|   3 +
 drivers/gpu/drm/i915/i915_guc_submission.c |  69 ++-
 drivers/gpu/drm/i915/intel_guc.h   |  46 +++--
 drivers/gpu/drm/i915/intel_guc_fwif.h  |  17 +-
 drivers/gpu/drm/i915/intel_guc_loader.c| 281 +
 drivers/gpu/drm/i915/intel_huc.h   |  44 +
 drivers/gpu/drm/i915/intel_huc_loader.c| 274 
 11 files changed, 634 insertions(+), 151 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_huc.h
 create mode 100644 drivers/gpu/drm/i915/intel_huc_loader.c

-- 
1.9.1

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

[Intel-gfx] [PATCH driver/intel] sna/cursor: Make sure hw cursors are disabled before disabling secondary planes

[Egbert Eich]

When the hw cursors are not disabled before the cursor planes get disabled
we may lose the cursor later on. Thus make sure the cursors are disabled
before the cursor planes are.

Signed-off-by: Egbert Eich 
---
 src/sna/sna_display.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/sna/sna_display.c b/src/sna/sna_display.c
index d790975..412c192 100644
--- a/src/sna/sna_display.c
+++ b/src/sna/sna_display.c
@@ -8081,6 +8081,9 @@ void sna_mode_check(struct sna *sna)
if (sna->mode.hidden)
return;
 
+/* make sure the hw cursors are disabled before disabling
+  the secondary planes which include the cursor plane */
+   sna_hide_cursors(sna->scrn);
disabled = sna_mode_disable_secondary_planes(sna);
 
/* Validate CRTC attachments and force consistency upon the kernel */
-- 
2.7.0

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

[Intel-gfx] [PATCH i-g-t 4/6] tests/kms_flip: Account for diff.tv_secs in jitter check

[ville . syrjala]

From: Ville Syrjälä 

Include diff.tv_secs in the jitter comparison.

Signed-off-by: Ville Syrjälä 
---
 tests/kms_flip.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/tests/kms_flip.c b/tests/kms_flip.c
index 743e4ad8f673..7718e950b823 100644
--- a/tests/kms_flip.c
+++ b/tests/kms_flip.c
@@ -643,7 +643,6 @@ static void vblank_handler(int fd, unsigned int frame, 
unsigned int sec,
 static void check_state(const struct test_output *o, const struct event_state 
*es)
 {
struct timeval diff;
-   double usec_interflip;
 
dump_event_state(es);
 
@@ -689,10 +688,13 @@ static void check_state(const struct test_output *o, 
const struct event_state *e
}
 
if ((o->flags & TEST_CHECK_TS) && (!analog_tv_connector(o))) {
+   double usec_interflip, usec_diff;
+
timersub(>current_ts, >last_ts, );
-   usec_interflip = (double)o->seq_step * frame_time(o);
+   usec_diff = diff.tv_sec * USEC_PER_SEC + diff.tv_usec;
 
-   igt_assert_f(fabsdouble) diff.tv_usec) - usec_interflip) /
+   usec_interflip = o->seq_step * frame_time(o);
+   igt_assert_f(fabs((usec_diff - usec_interflip) /
  usec_interflip) <= 0.005,
 "inter-%s ts jitter: %ld.%06ld\n",
 es->name, diff.tv_sec, diff.tv_usec);
-- 
2.7.4

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

[Intel-gfx] [PATCH i-g-t 3/6] tests/kms_flip: Use USEC_PER_SEC

[ville . syrjala]

From: Ville Syrjälä 

Replace some opencoded numbers with USEC_PER_SEC, and
print the usec_diff with 6 decimal digits to make things
more consistent.

Signed-off-by: Ville Syrjälä 
---
 tests/kms_flip.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tests/kms_flip.c b/tests/kms_flip.c
index 7b526b5e8593..743e4ad8f673 100644
--- a/tests/kms_flip.c
+++ b/tests/kms_flip.c
@@ -717,15 +717,15 @@ static void check_state_correlation(struct test_output *o,
return;
 
timersub(>current_ts, >current_ts, _diff);
-   usec_diff = tv_diff.tv_sec * 1000 * 1000 + tv_diff.tv_usec;
+   usec_diff = tv_diff.tv_sec * USEC_PER_SEC + tv_diff.tv_usec;
 
seq_diff = es2->current_seq - es1->current_seq;
ftime = frame_time(o);
usec_diff -= seq_diff * ftime;
 
igt_assert_f(fabs(usec_diff) / ftime <= 0.005,
-"timestamp mismatch between %s and %s (diff %.4f sec)\n",
-es1->name, es2->name, usec_diff / 1000 / 1000);
+"timestamp mismatch between %s and %s (diff %.6f sec)\n",
+es1->name, es2->name, usec_diff / USEC_PER_SEC);
 }
 
 static void check_all_state(struct test_output *o,
-- 
2.7.4

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

[Intel-gfx] [PATCH i-g-t 6/6] tests/kms_flip: Check that the last vs. current seq/ts are consistent

[ville . syrjala]

From: Ville Syrjälä 

Let's make sure the ts vs. seq difference between the current and last
events match.

Signed-off-by: Ville Syrjälä 
---
 tests/kms_flip.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/tests/kms_flip.c b/tests/kms_flip.c
index f685c945feb1..72899d9a7157 100644
--- a/tests/kms_flip.c
+++ b/tests/kms_flip.c
@@ -693,6 +693,13 @@ static void check_state(const struct test_output *o, const 
struct event_state *e
timersub(>current_ts, >last_ts, );
usec_diff = diff.tv_sec * USEC_PER_SEC + diff.tv_usec;
 
+   usec_interflip = (es->current_seq - es->last_seq) * 
frame_time(o);
+   igt_assert_f(fabs((usec_diff - usec_interflip) /
+ usec_interflip) <= 0.005,
+"inconsistent %s ts/seq: last %ld.%06ld/%u, 
current %ld.%06ld/%u\n",
+es->name, es->last_ts.tv_sec, es->last_ts.tv_usec, 
es->last_seq,
+es->current_ts.tv_sec, es->current_ts.tv_usec, 
es->current_seq);
+
usec_interflip = o->seq_step * frame_time(o);
igt_assert_f(fabs((usec_diff - usec_interflip) /
  usec_interflip) <= 0.005,
-- 
2.7.4

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

[Intel-gfx] [PATCH i-g-t 2/6] tests/kms_flip: Constify some function arguments

[ville . syrjala]

From: Ville Syrjälä 

Signed-off-by: Ville Syrjälä 
---
 tests/kms_flip.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/tests/kms_flip.c b/tests/kms_flip.c
index f61d199b648f..7b526b5e8593 100644
--- a/tests/kms_flip.c
+++ b/tests/kms_flip.c
@@ -531,7 +531,7 @@ static int do_wait_for_vblank(struct test_output *o, int 
pipe_id,
 }
 
 static bool
-analog_tv_connector(struct test_output *o)
+analog_tv_connector(const struct test_output *o)
 {
uint32_t connector_type = o->kconnector[0]->connector_type;
 
@@ -574,7 +574,7 @@ static void page_flip_handler(int fd, unsigned int frame, 
unsigned int sec,
event_handler(>flip_state, frame, sec, usec);
 }
 
-static double frame_time(struct test_output *o)
+static double frame_time(const struct test_output *o)
 {
return 1000.0 * o->kmode[0].htotal * o->kmode[0].vtotal / 
o->kmode[0].clock;
 }
@@ -640,7 +640,7 @@ static void vblank_handler(int fd, unsigned int frame, 
unsigned int sec,
fixup_premature_vblank_ts(o, >vblank_state);
 }
 
-static void check_state(struct test_output *o, struct event_state *es)
+static void check_state(const struct test_output *o, const struct event_state 
*es)
 {
struct timeval diff;
double usec_interflip;
@@ -1173,7 +1173,8 @@ fb_is_bound(struct test_output *o, int fb)
return true;
 }
 
-static void check_final_state(struct test_output *o, struct event_state *es,
+static void check_final_state(const struct test_output *o,
+ const struct event_state *es,
  unsigned int elapsed)
 {
igt_assert_f(es->count > 0,
-- 
2.7.4

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

[Intel-gfx] [PATCH i-g-t 5/6] tests/kms_flip: Print the expected diff between two events

[ville . syrjala]

From: Ville Syrjälä 

To aid in diagnosing failures, print out the expected time
difference between the two events.

Signed-off-by: Ville Syrjälä 
---
 tests/kms_flip.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/tests/kms_flip.c b/tests/kms_flip.c
index 7718e950b823..f685c945feb1 100644
--- a/tests/kms_flip.c
+++ b/tests/kms_flip.c
@@ -696,8 +696,9 @@ static void check_state(const struct test_output *o, const 
struct event_state *e
usec_interflip = o->seq_step * frame_time(o);
igt_assert_f(fabs((usec_diff - usec_interflip) /
  usec_interflip) <= 0.005,
-"inter-%s ts jitter: %ld.%06ld\n",
-es->name, diff.tv_sec, diff.tv_usec);
+"inter-%s ts jitter: %ld.%06ld, expected %.6f\n",
+es->name, diff.tv_sec, diff.tv_usec,
+usec_interflip / USEC_PER_SEC);
 
igt_assert_f(es->current_seq == es->last_seq + o->seq_step,
 "unexpected %s seq %u, expected %u\n",
-- 
2.7.4

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

[Intel-gfx] [PATCH i-g-t 1/6] tests/kms_flip: Print timestamps in a consistent form

[ville . syrjala]

From: Ville Syrjälä 

Signed-off-by: Ville Syrjälä 
---
 tests/kms_flip.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/tests/kms_flip.c b/tests/kms_flip.c
index 6ec97d0a8534..f61d199b648f 100644
--- a/tests/kms_flip.c
+++ b/tests/kms_flip.c
@@ -132,11 +132,11 @@ struct event_state {
 static void dump_event_state(const struct event_state *es)
 {
igt_debug("name = %s\n"
- "last_ts = %ld.%ld usec\n"
- "last_received_ts = %ld.%ld usec\n"
+ "last_ts = %ld.%06ld\n"
+ "last_received_ts = %ld.%06ld\n"
  "last_seq = %u\n"
- "current_ts = %ld.%ld usec\n"
- "current_received_ts = %ld.%ld usec\n"
+ "current_ts = %ld.%06ld\n"
+ "current_received_ts = %ld.%06ld\n"
  "current_seq = %u\n"
  "count = %u\n"
  "seq_step = %d\n",
@@ -650,7 +650,7 @@ static void check_state(struct test_output *o, struct 
event_state *es)
timersub(>current_ts, >current_received_ts, );
if (!analog_tv_connector(o)) {
igt_assert_f(diff.tv_sec < 0 || (diff.tv_sec == 0 && 
diff.tv_usec <= 2000),
-"%s ts delayed for too long: %lds, %ldusec\n",
+"%s ts delayed for too long: %ld.%06ld\n",
 es->name, diff.tv_sec, diff.tv_usec);
 
}
@@ -661,7 +661,7 @@ static void check_state(struct test_output *o, struct 
event_state *es)
timersub(>current_ts, >last_received_ts, );
igt_assert_f(timercmp(>last_received_ts, >current_ts, <),
 "%s ts before the %s was issued!\n"
-"timerdiff %lds, %ldusec\n",
+"timerdiff %ld.%06ld\n",
 es->name, es->name,
 diff.tv_sec, diff.tv_usec);
 
@@ -694,7 +694,7 @@ static void check_state(struct test_output *o, struct 
event_state *es)
 
igt_assert_f(fabsdouble) diff.tv_usec) - usec_interflip) /
  usec_interflip) <= 0.005,
-"inter-%s ts jitter: %lds, %ldusec\n",
+"inter-%s ts jitter: %ld.%06ld\n",
 es->name, diff.tv_sec, diff.tv_usec);
 
igt_assert_f(es->current_seq == es->last_seq + o->seq_step,
-- 
2.7.4

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

[Intel-gfx] [PATCH v3 2/4] drm/i915/vlv: Reset the ADPA in vlv_display_power_well_init()

[Lyude]

While VGA hotplugging worked(ish) before, it looks like that was mainly
because we'd unintentionally enable it in
valleyview_crt_detect_hotplug() when we did a force trigger. This
doesn't work reliably enough because whenever the display powerwell on
vlv gets disabled, the values set in VLV_ADPA get cleared and
consequently VGA hotplugging gets disabled. This causes bugs such as one
we found on an Intel NUC, where doing the following sequence of
hotplugs:

  - Disconnect all monitors
  - Connect VGA
  - Disconnect VGA
  - Connect HDMI

Would result in VGA hotplugging becoming disabled, due to the powerwells
getting toggled in the process of connecting HDMI.

Changes since v3:
 - Expose intel_crt_reset() through intel_drv.h and call that in
   vlv_display_power_well_init() instead of
   encoder->base.funcs->reset(>base);

Changes since v2:
 - Use intel_encoder structs instead of drm_encoder structs

Changes since v1:
 - Instead of handling the register writes ourself, we just reuse
   intel_crt_detect()
 - Instead of resetting the ADPA during display IRQ installation, we now
   reset them in vlv_display_power_well_init()

Cc: sta...@vger.kernel.org
Acked-by: Daniel Vetter 
Signed-off-by: Lyude 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_crt.c| 2 +-
 drivers/gpu/drm/i915/intel_drv.h| 2 +-
 drivers/gpu/drm/i915/intel_runtime_pm.c | 7 +++
 3 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index dfcd718..220be7a 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -713,7 +713,7 @@ static int intel_crt_set_property(struct drm_connector 
*connector,
return 0;
 }
 
-static void intel_crt_reset(struct drm_encoder *encoder)
+void intel_crt_reset(struct drm_encoder *encoder)
 {
struct drm_device *dev = encoder->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 496c962..dcbfdde 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1075,7 +1075,7 @@ void gen8_irq_power_well_pre_disable(struct 
drm_i915_private *dev_priv,
 
 /* intel_crt.c */
 void intel_crt_init(struct drm_device *dev);
-
+void intel_crt_reset(struct drm_encoder *encoder);
 
 /* intel_ddi.c */
 void intel_ddi_clk_select(struct intel_encoder *encoder,
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index e856d49..f88ef76 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -1065,6 +1065,7 @@ static void vlv_init_display_clock_gating(struct 
drm_i915_private *dev_priv)
 
 static void vlv_display_power_well_init(struct drm_i915_private *dev_priv)
 {
+   struct intel_encoder *encoder;
enum pipe pipe;
 
/*
@@ -1100,6 +1101,12 @@ static void vlv_display_power_well_init(struct 
drm_i915_private *dev_priv)
 
intel_hpd_init(dev_priv);
 
+   /* Re-enable the ADPA, if we have one */
+   for_each_intel_encoder(dev_priv->dev, encoder) {
+   if (encoder->type == INTEL_OUTPUT_ANALOG)
+   intel_crt_reset(>base);
+   }
+
i915_redisable_vga_power_on(dev_priv->dev);
 }
 
-- 
2.5.5

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

[Intel-gfx] [PATCH v3 3/4] drm/i915/vlv: Disable HPD in valleyview_crt_detect_hotplug()

[Lyude]

One of the things preventing us from using polling is the fact that
calling valleyview_crt_detect_hotplug() when there's a VGA cable
connected results in sending another hotplug. With polling enabled when
HPD is disabled, this results in a scenario like this:

- We enable power wells and reset the ADPA
- output_poll_exec does force probe on VGA, triggering a hpd
- HPD handler waits for poll to unlock dev->mode_config.mutex
- output_poll_exec shuts off the ADPA, unlocks dev->mode_config.mutex
- HPD handler runs, resets ADPA and brings us back to the start

This results in an endless irq storm getting sent from the ADPA
whenever a VGA connector gets detected in the middle of polling.

Somewhat based off of the "drm/i915: Disable CRT HPD around force
trigger" patch Ville Syrjälä sent a while back

Cc: sta...@vger.kernel.org
Cc: Ville Syrjälä 
Signed-off-by: Lyude 
---
 drivers/gpu/drm/i915/i915_drv.h  |  2 ++
 drivers/gpu/drm/i915/intel_crt.c | 18 ++
 drivers/gpu/drm/i915/intel_hotplug.c | 27 +++
 3 files changed, 47 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a988a95..239a3ec 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2933,6 +2933,8 @@ void intel_hpd_init(struct drm_i915_private *dev_priv);
 void intel_hpd_init_work(struct drm_i915_private *dev_priv);
 void intel_hpd_cancel_work(struct drm_i915_private *dev_priv);
 bool intel_hpd_pin_to_port(enum hpd_pin pin, enum port *port);
+bool intel_hpd_disable(struct drm_i915_private *dev_priv, enum hpd_pin pin);
+void intel_hpd_enable(struct drm_i915_private *dev_priv, enum hpd_pin pin);
 
 /* i915_irq.c */
 void i915_queue_hangcheck(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 220be7a..a626793 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -327,10 +327,25 @@ static bool valleyview_crt_detect_hotplug(struct 
drm_connector *connector)
struct drm_device *dev = connector->dev;
struct intel_crt *crt = intel_attached_crt(connector);
struct drm_i915_private *dev_priv = dev->dev_private;
+   bool reenable_hpd;
u32 adpa;
bool ret;
u32 save_adpa;
 
+   /*
+* Doing a force trigger causes a hpd interrupt to get sent, which can
+* get us stuck in a loop if we're polling:
+*  - We enable power wells and reset the ADPA
+*  - output_poll_exec does force probe on VGA, triggering a hpd
+*  - HPD handler waits for poll to unlock dev->mode_config.mutex
+*  - output_poll_exec shuts off the ADPA, unlocks
+*dev->mode_config.mutex
+*  - HPD handler runs, resets ADPA and brings us back to the start
+*
+* Just disable HPD interrupts here to prevent this
+*/
+   reenable_hpd = intel_hpd_disable(dev_priv, crt->base.hpd_pin);
+
save_adpa = adpa = I915_READ(crt->adpa_reg);
DRM_DEBUG_KMS("trigger hotplug detect cycle: adpa=0x%x\n", adpa);
 
@@ -353,6 +368,9 @@ static bool valleyview_crt_detect_hotplug(struct 
drm_connector *connector)
 
DRM_DEBUG_KMS("valleyview hotplug adpa=0x%x, result %d\n", adpa, ret);
 
+   if (reenable_hpd)
+   intel_hpd_enable(dev_priv, crt->base.hpd_pin);
+
return ret;
 }
 
diff --git a/drivers/gpu/drm/i915/intel_hotplug.c 
b/drivers/gpu/drm/i915/intel_hotplug.c
index 38eeca7..ec3285f 100644
--- a/drivers/gpu/drm/i915/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/intel_hotplug.c
@@ -510,3 +510,30 @@ void intel_hpd_cancel_work(struct drm_i915_private 
*dev_priv)
cancel_work_sync(_priv->hotplug.hotplug_work);
cancel_delayed_work_sync(_priv->hotplug.reenable_work);
 }
+
+bool intel_hpd_disable(struct drm_i915_private *dev_priv, enum hpd_pin pin)
+{
+   bool ret = false;
+
+   if (pin == HPD_NONE)
+   return false;
+
+   spin_lock_irq(_priv->irq_lock);
+   if (dev_priv->hotplug.stats[pin].state == HPD_ENABLED) {
+   dev_priv->hotplug.stats[pin].state = HPD_DISABLED;
+   ret = true;
+   }
+   spin_unlock_irq(_priv->irq_lock);
+
+   return ret;
+}
+
+void intel_hpd_enable(struct drm_i915_private *dev_priv, enum hpd_pin pin)
+{
+   if (pin == HPD_NONE)
+   return;
+
+   spin_lock_irq(_priv->irq_lock);
+   dev_priv->hotplug.stats[pin].state = HPD_ENABLED;
+   spin_unlock_irq(_priv->irq_lock);
+}
-- 
2.5.5

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

[Intel-gfx] [PATCH v3 1/4] drm/i915/vlv: Make intel_crt_reset() per-encoder

[Lyude]

This lets call intel_crt_reset() in contexts where IRQs are disabled and
as such, can't hold the locks required to work with the connectors.

Cc: sta...@vger.kernel.org
Cc: Ville Syrjälä 
Acked-by: Daniel Vetter 
Signed-off-by: Lyude 
---
 drivers/gpu/drm/i915/intel_crt.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index e115bcc..dfcd718 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -713,11 +713,11 @@ static int intel_crt_set_property(struct drm_connector 
*connector,
return 0;
 }
 
-static void intel_crt_reset(struct drm_connector *connector)
+static void intel_crt_reset(struct drm_encoder *encoder)
 {
-   struct drm_device *dev = connector->dev;
+   struct drm_device *dev = encoder->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
-   struct intel_crt *crt = intel_attached_crt(connector);
+   struct intel_crt *crt = intel_encoder_to_crt(to_intel_encoder(encoder));
 
if (INTEL_INFO(dev)->gen >= 5) {
u32 adpa;
@@ -739,7 +739,6 @@ static void intel_crt_reset(struct drm_connector *connector)
  */
 
 static const struct drm_connector_funcs intel_crt_connector_funcs = {
-   .reset = intel_crt_reset,
.dpms = drm_atomic_helper_connector_dpms,
.detect = intel_crt_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
@@ -757,6 +756,7 @@ static const struct drm_connector_helper_funcs 
intel_crt_connector_helper_funcs
 };
 
 static const struct drm_encoder_funcs intel_crt_enc_funcs = {
+   .reset = intel_crt_reset,
.destroy = intel_encoder_destroy,
 };
 
@@ -901,5 +901,5 @@ void intel_crt_init(struct drm_device *dev)
dev_priv->fdi_rx_config = I915_READ(FDI_RX_CTL(PIPE_A)) & 
fdi_config;
}
 
-   intel_crt_reset(connector);
+   intel_crt_reset(>base.base);
 }
-- 
2.5.5

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

[Intel-gfx] [PATCH v3 4/4] drm/i915: Enable polling when we don't have hpd

[Lyude]

Unfortunately, there's two situations where we lose hpd right now:
- Runtime suspend
- When we've shut off all of the power wells on Valleyview/Cherryview

While it would be nice if this didn't cause issues, this has the
ability to get us in some awkward states where a user won't be able to
get their display to turn on. For instance; if we boot a Valleyview
system without any monitors connected, it won't need any of it's power
wells and thus shut them off. Since this causes us to lose HPD, this
means that unless the user knows how to ssh into their machine and do a
manual reprobe for monitors, none of the monitors they connect after
booting will actually work.

Eventually we should come up with a better fix then having to enable
polling for this, since this makes rpm a lot less useful, but for now
the infrastructure in i915 just isn't there yet to get hpd in these
situations.

Changes since v1:
 - Add comment explaining the addition of the if
   (!mode_config->poll_running) in intel_hpd_init()
 - Remove unneeded if (!dev->mode_config.poll_enabled) in
   i915_hpd_poll_init_work()
 - Call to drm_helper_hpd_irq_event() after we disable polling
 - Add cancel_work_sync() call to intel_hpd_cancel_work()

Changes since v2:
 - Apparently dev->mode_config.poll_running doesn't actually reflect
   whether or not a poll is currently in progress, and is actually used
   for dynamic module paramter enabling/disabling. So now we instead
   keep track of our own poll_running variable in dev_priv->hotplug
 - Clean i915_hpd_poll_init_work() a little bit

Cc: sta...@vger.kernel.org
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Signed-off-by: Lyude 
---
 drivers/gpu/drm/i915/i915_drv.c |  7 ++-
 drivers/gpu/drm/i915/i915_drv.h |  4 ++
 drivers/gpu/drm/i915/intel_drv.h|  2 +
 drivers/gpu/drm/i915/intel_hotplug.c| 85 +
 drivers/gpu/drm/i915/intel_runtime_pm.c |  3 ++
 5 files changed, 90 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 3eb47fb..5381d9e 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1612,6 +1612,9 @@ static int intel_runtime_suspend(struct device *device)
 
assert_forcewakes_inactive(dev_priv);
 
+   if (!IS_VALLEYVIEW(dev_priv) || !IS_CHERRYVIEW(dev_priv))
+   intel_hpd_poll_enable(dev_priv, true);
+
DRM_DEBUG_KMS("Device suspended\n");
return 0;
 }
@@ -1667,8 +1670,10 @@ static int intel_runtime_resume(struct device *device)
 * power well, so hpd is reinitialized from there. For
 * everyone else do it here.
 */
-   if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv))
+   if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv)) {
intel_hpd_init(dev_priv);
+   intel_hpd_poll_enable(dev_priv, false);
+   }
 
intel_enable_gt_powersave(dev_priv);
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 239a3ec..36a9d90 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -283,6 +283,10 @@ struct i915_hotplug {
u32 short_port_mask;
struct work_struct dig_port_work;
 
+   struct work_struct poll_enable_work;
+   bool poll_enabled;
+   bool poll_running;
+
/*
 * if we get a HPD irq from DP and a HPD irq from non-DP
 * the non-DP HPD could block the workqueue on a mode config
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index dcbfdde..cedac13 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1385,6 +1385,8 @@ int intel_dsi_dcs_init_backlight_funcs(struct 
intel_connector *intel_connector);
 
 /* intel_dvo.c */
 void intel_dvo_init(struct drm_device *dev);
+/* intel_hotplug.c */
+void intel_hpd_poll_enable(struct drm_i915_private *dev_priv, bool enabled);
 
 
 /* legacy fbdev emulation in intel_fbdev.c */
diff --git a/drivers/gpu/drm/i915/intel_hotplug.c 
b/drivers/gpu/drm/i915/intel_hotplug.c
index ec3285f..1fc36a5 100644
--- a/drivers/gpu/drm/i915/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/intel_hotplug.c
@@ -464,20 +464,34 @@ void intel_hpd_init(struct drm_i915_private *dev_priv)
dev_priv->hotplug.stats[i].count = 0;
dev_priv->hotplug.stats[i].state = HPD_ENABLED;
}
-   list_for_each_entry(connector, _config->connector_list, head) {
-   struct intel_connector *intel_connector = 
to_intel_connector(connector);
-   connector->polled = intel_connector->polled;
 
-   /* MST has a dynamic intel_connector->encoder and it's reprobing
-* is all handled by the MST helpers. */
-   if (intel_connector->mst_port)
-   continue;
+   /*
+* When we're in the midst 

[Intel-gfx] [PATCH v3 0/4] Fixes for HPD

[Lyude]

This is a revised version of the patchset:

https://lists.freedesktop.org/archives/intel-gfx/2016-June/098787.html

This patchset is intended to fix the issue of not having HPD when we're in
runtime suspend, or on Valleyview/Cherryview systems when we don't have any
power wells enabled. While this isn't the best for RPM, until we have the
infrastructure to provide hpd while in runtime suspend this will have to
suffice since not having HPD at all times means a user could potentially boot
their system with no displays connected, then never have any displays they
connect afterwards get detected.

Unlike the previous patchset, this patchset includes a fix for the VGA detect
loops we were seeing on Valleyview. On my setup, this fix seems to have fixed
the loop entirely. As it turns out, I think our original understanding of this
issue wasn't entirely accurate. Originally it had been assumed that the HPD
signals we were getting from the ADPA were a result of turning the power wells
on and off. As it turns out, the HPD signals actually don't get fired off until
we do the force detect on the ADPA, not when we reset it. This means this
problem can easily be solved just by temporarily disabling HPD on the ADPA
whenever we do a force detect.

As such, "drm/i915/vlv: Disable HPD in valleyview_crt_detect_hotplug()"
deprecates Ville's previous two fixes

Cc: sta...@vger.kernel.org
Cc: Ville Syrjälä 
Cc: Daniel Vetter 

Lyude (4):
  drm/i915/vlv: Make intel_crt_reset() per-encoder
  drm/i915/vlv: Reset the ADPA in vlv_display_power_well_init()
  drm/i915/vlv: Disable HPD in valleyview_crt_detect_hotplug()
  drm/i915: Enable polling when we don't have hpd

 drivers/gpu/drm/i915/i915_drv.c |   7 +-
 drivers/gpu/drm/i915/i915_drv.h |   6 ++
 drivers/gpu/drm/i915/intel_crt.c|  28 ++--
 drivers/gpu/drm/i915/intel_drv.h|   4 +-
 drivers/gpu/drm/i915/intel_hotplug.c| 112 +---
 drivers/gpu/drm/i915/intel_runtime_pm.c |  10 +++
 6 files changed, 150 insertions(+), 17 deletions(-)

-- 
2.5.5

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

Re: [Intel-gfx] [PATCH v10b 4/6] drm/i915: Interrupt driven fences

[Tvrtko Ursulin]

On 21/06/16 11:44, Tvrtko Ursulin wrote:


On 17/06/16 12:05, john.c.harri...@intel.com wrote:

From: John Harrison 

The intended usage model for struct fence is that the signalled status
should be set on demand rather than polled. That is, there should not
be a need for a 'signaled' function to be called everytime the status
is queried. Instead, 'something' should be done to enable a signal
callback from the hardware which will update the state directly. In
the case of requests, this is the seqno update interrupt. The idea is
that this callback will only be enabled on demand when something
actually tries to wait on the fence.

This change removes the polling test and replaces it with the callback
scheme. Each fence is added to a 'please poke me' list at the start of
i915_add_request(). The interrupt handler (via a deferred work queue)
then scans through the 'poke me' list when a new seqno pops out and
signals any matching fence/request. The fence is then removed from the
list so the entire request stack does not need to be scanned every
time. The fence is added to the list before the commands to generate
the seqno interrupt are added to the ring. Thus the sequence is
guaranteed to be race free if the interrupt is already enabled.

Note that the interrupt is only enabled on demand (i.e. when
__wait_request() is called). Thus there is still a potential race when
enabling the interrupt as the request may already have completed.
However, this is simply solved by calling the interrupt processing
code immediately after enabling the interrupt and thereby checking for
already completed requests.

Lastly, the ring clean up code has the possibility to cancel
outstanding requests (e.g. because TDR has reset the ring). These
requests will never get signalled and so must be removed from the
signal list manually. This is done by setting a 'cancelled' flag and
then calling the regular notify/retire code path rather than
attempting to duplicate the list manipulatation and clean up code in
multiple places. This also avoids any race condition where the
cancellation request might occur after/during the completion interrupt
actually arriving.

v2: Updated to take advantage of the request unreference no longer
requiring the mutex lock.

v3: Move the signal list processing around to prevent unsubmitted
requests being added to the list. This was occurring on Android
because the native sync implementation calls the
fence->enable_signalling API immediately on fence creation.

Updated after review comments by Tvrtko Ursulin. Renamed list nodes to
'link' instead of 'list'. Added support for returning an error code on
a cancelled fence. Update list processing to be more efficient/safer
with respect to spinlocks.

v5: Made i915_gem_request_submit a static as it is only ever called
from one place.

Fixed up the low latency wait optimisation. The time delay between the
seqno value being to memory and the drive's ISR running can be
significant, at least for the wait request micro-benchmark. This can
be greatly improved by explicitly checking for seqno updates in the
pre-wait busy poll loop. Also added some documentation comments to the
busy poll code.

Fixed up support for the faking of lost interrupts
(test_irq_rings/missed_irq_rings). That is, there is an IGT test that
tells the driver to loose interrupts deliberately and then check that
everything still works as expected (albeit much slower).

Updates from review comments: use non IRQ-save spinlocking, early exit
on WARN and improved comments (Tvrtko Ursulin).

v6: Updated to newer nigthly and resolved conflicts around the
wait_request busy spin optimisation. Also fixed a race condition
between this early exit path and the regular completion path.

v7: Updated to newer nightly - lots of ring -> engine renaming plus an
interface change on get_seqno(). Also added a list_empty() check
before acquring spinlocks and doing list processing.

v8: Updated to newer nightly - changes to request clean up code mean
non of the deferred free mess is needed any more.

v9: Moved the request completion processing out of the interrupt
handler and into a worker thread (Chris Wilson).

v10: Changed to an un-ordered work queue to allow parallel processing
of different engines. Also set the high priority flag for reduced
latency. Removed some unnecessary checks for invalid seqno values.
Improved/added some comments and WARNs. Moved a spinlock release a few
lines later to make the 'locked' parameter of
i915_gem_request_enable_interrupt redundant and removed it. Also
shuffled the function around in the file so as to make it static and
remove it from the header file. Corrected the use of
fence_signal_locked() to fence_signal() in the retire code. Dropped
the irq save part of the spin lock calls in the notify code as this is
no longer called from the ISR. Changed the call of
i915_gem_retire_requests_ring() in the reset cleanup code to
i915_gem_request_notify() instead as the 

[Intel-gfx] [PATCH i-g-t 3/3] tools/intel_bios_reader: Dump out more of the eDP block

[ville . syrjala]

From: Ville Syrjälä 

Signed-off-by: Ville Syrjälä 
---
 tools/intel_bios.h|  26 ---
 tools/intel_bios_reader.c | 108 ++
 2 files changed, 120 insertions(+), 14 deletions(-)

diff --git a/tools/intel_bios.h b/tools/intel_bios.h
index ac8c8650272d..925bb06cd110 100644
--- a/tools/intel_bios.h
+++ b/tools/intel_bios.h
@@ -658,21 +658,37 @@ struct edp_power_seq {
uint16_t t12;
 } __attribute__ ((packed));
 
-struct edp_link_params {
+struct edp_fast_link_params {
uint8_t rate:4;
uint8_t lanes:4;
uint8_t preemphasis:4;
uint8_t vswing:4;
 } __attribute__ ((packed));
 
-struct bdb_edp {
+struct edp_pwm_delays {
+   uint16_t pwm_on_to_backlight_enable;
+   uint16_t backlight_disable_to_pwm_off;
+} __attribute__ ((packed));
+
+struct edp_full_link_params {
+   uint8_t preemphasis:4;
+   uint8_t vswing:4;
+} __attribute__ ((packed));
+
+struct bdb_edp { /* 155 */
struct edp_power_seq power_seqs[16];
uint32_t color_depth;
-   struct edp_link_params link_params[16];
+   struct edp_fast_link_params fast_link_params[16];
uint32_t sdrrs_msa_timing_delay;
 
-   uint16_t edp_s3d_feature;
-   uint16_t edp_t3_optimization;
+   uint16_t s3d_feature; /* 163 */
+   uint16_t t3_optimization; /* 165 */
+   uint64_t vswing_preemph_table_selection; /* 173 */
+   uint16_t fast_link_training; /* 182 */
+   uint16_t dpcd_600h_write_required; /* 185 */
+   struct edp_pwm_delays pwm_delays[16]; /* 186 */
+   uint16_t full_link_params_provided; /* 199 */
+   struct edp_full_link_params full_link_params[16]; /* 199 */
 } __attribute__ ((packed));
 
 
diff --git a/tools/intel_bios_reader.c b/tools/intel_bios_reader.c
index 3aefe2b1aacf..e3daa7424580 100644
--- a/tools/intel_bios_reader.c
+++ b/tools/intel_bios_reader.c
@@ -754,14 +754,14 @@ static void dump_edp(struct context *context,
msa = (edp->sdrrs_msa_timing_delay >> (i * 2)) & 3;
printf("\t\teDP sDRRS MSA Delay: Lane %d\n", msa + 1);
 
-   printf("\t\tLink params:\n");
+   printf("\t\tFast link params:\n");
printf("\t\t\trate: ");
-   if (edp->link_params[i].rate == EDP_RATE_1_62)
+   if (edp->fast_link_params[i].rate == EDP_RATE_1_62)
printf("1.62G\n");
-   else if (edp->link_params[i].rate == EDP_RATE_2_7)
+   else if (edp->fast_link_params[i].rate == EDP_RATE_2_7)
printf("2.7G\n");
printf("\t\t\tlanes: ");
-   switch (edp->link_params[i].lanes) {
+   switch (edp->fast_link_params[i].lanes) {
case EDP_LANE_1:
printf("x1 mode\n");
break;
@@ -773,11 +773,11 @@ static void dump_edp(struct context *context,
break;
default:
printf("(unknown value %d)\n",
-  edp->link_params[i].lanes);
+  edp->fast_link_params[i].lanes);
break;
}
printf("\t\t\tpre-emphasis: ");
-   switch (edp->link_params[i].preemphasis) {
+   switch (edp->fast_link_params[i].preemphasis) {
case EDP_PREEMPHASIS_NONE:
printf("none\n");
break;
@@ -792,11 +792,11 @@ static void dump_edp(struct context *context,
break;
default:
printf("(unknown value %d)\n",
-  edp->link_params[i].preemphasis);
+  edp->fast_link_params[i].preemphasis);
break;
}
printf("\t\t\tvswing: ");
-   switch (edp->link_params[i].vswing) {
+   switch (edp->fast_link_params[i].vswing) {
case EDP_VSWING_0_4V:
printf("0.4V\n");
break;
@@ -811,9 +811,99 @@ static void dump_edp(struct context *context,
break;
default:
printf("(unknown value %d)\n",
-  edp->link_params[i].vswing);
+  edp->fast_link_params[i].vswing);
break;
}
+
+   if (context->bdb->version >= 162) {
+   bool val = (edp->s3d_feature >> i) & 1;
+   printf("\t\tStereo 3D feature: %s\n", YESNO(val));
+   }
+
+   if (context->bdb->version >= 165) {
+   bool val = (edp->t3_optimization >> i) & 1;
+   printf("\t\tT3 optimization: %s\n", YESNO(val));
+   }
+
+   if 

[Intel-gfx] [PATCH i-g-t 1/3] tools/intel_bios_reader: Dump more bits for general bit definitions block (1)

[ville . syrjala]

From: Ville Syrjälä 

Signed-off-by: Ville Syrjälä 
---
 tools/intel_bios.h| 17 ++---
 tools/intel_bios_reader.c | 35 +--
 2 files changed, 47 insertions(+), 5 deletions(-)

diff --git a/tools/intel_bios.h b/tools/intel_bios.h
index b7ebd48ef7e7..c4632da336d9 100644
--- a/tools/intel_bios.h
+++ b/tools/intel_bios.h
@@ -104,12 +104,19 @@ struct bdb_general_features {
unsigned char ssc_freq:1;
unsigned char enable_lfp_on_override:1;
unsigned char disable_ssc_ddt:1;
-   unsigned char rsvd8:3;  /* finish byte */
+   unsigned char underscan_vga_timings:1;
+   unsigned char dynamic_cdclk:1; /* 183 */
+   unsigned char vbios_hotplug_support:1;
 
/* bits 3 */
unsigned char disable_smooth_vision:1;
unsigned char single_dvi:1;
-   unsigned char rsvd9:6;  /* finish byte */
+   unsigned char rotate_180:1; /* 181 */
+   unsigned char fdi_rx_polarity:1;
+   unsigned char vbios_extended_mode:1; /* 160 */
+   unsigned char copy_ilfp_dtd_to_sdvo_lvds_dtd:1; /* 160 */
+   unsigned char panel_best_fit_timing:1; /* 160 */
+   unsigned char ignore_strap_state:1; /* 160 */
 
/* bits 4 */
unsigned char legacy_monitor_detect;
@@ -117,7 +124,11 @@ struct bdb_general_features {
/* bits 5 */
unsigned char int_crt_support:1;
unsigned char int_tv_support:1;
-   unsigned char rsvd11:6; /* finish byte */
+   unsigned char int_efp_support:1;
+   unsigned char dp_ssc_enable:1;
+   unsigned char dp_ssc_freq:1;
+   unsigned char dp_ssc_dongle_supported:1;
+   unsigned char rsvd11:2; /* finish byte */
 } __attribute__ ((packed));
 
 #define GPIO_PIN_NONE  0x00/* "N/A" */
diff --git a/tools/intel_bios_reader.c b/tools/intel_bios_reader.c
index 4c4ab666fc55..588cc2c36c7a 100644
--- a/tools/intel_bios_reader.c
+++ b/tools/intel_bios_reader.c
@@ -151,6 +151,7 @@ static void dump_general_features(struct context *context,
printf("\tMessage: %s\n", YESNO(features->msg_enable));
printf("\tClear screen: %d\n", features->clear_screen);
printf("\tDVO color flip required: %s\n", YESNO(features->color_flip));
+
printf("\tExternal VBT: %s\n", YESNO(features->download_ext_vbt));
printf("\tEnable SSC: %s\n", YESNO(features->enable_ssc));
if (features->enable_ssc) {
@@ -171,13 +172,45 @@ static void dump_general_features(struct context *context,
   YESNO(features->enable_lfp_on_override));
printf("\tDisable SSC on clone: %s\n",
   YESNO(features->disable_ssc_ddt));
+   printf("\tUnderscan support for VGA timings: %s\n",
+  YESNO(features->underscan_vga_timings));
+   if (context->bdb->version >= 183)
+   printf("\tDynamic CD clock: %s\n", 
YESNO(features->dynamic_cdclk));
+   printf("\tHotplug support in VBIOS: %s\n",
+  YESNO(features->vbios_hotplug_support));
+
printf("\tDisable smooth vision: %s\n",
   YESNO(features->disable_smooth_vision));
printf("\tSingle DVI for CRT/DVI: %s\n", YESNO(features->single_dvi));
+   if (context->bdb->version >= 181)
+   printf("\tEnable 180 degree rotation: %s\n", 
YESNO(features->rotate_180));
+   printf("\tInverted FDI Rx polarity: %s\n", 
YESNO(features->fdi_rx_polarity));
+   if (context->bdb->version >= 160) {
+   printf("\tExtended VBIOS mode: %s\n", 
YESNO(features->vbios_extended_mode));
+   printf("\tCopy iLFP DTD to SDVO LVDS DTD: %s\n", 
YESNO(features->copy_ilfp_dtd_to_sdvo_lvds_dtd));
+   printf("\tBest fit panel timing algorithm: %s\n", 
YESNO(features->panel_best_fit_timing));
+   printf("\tIgnore strap state: %s\n", 
YESNO(features->ignore_strap_state));
+   }
+
printf("\tLegacy monitor detect: %s\n",
   YESNO(features->legacy_monitor_detect));
+
printf("\tIntegrated CRT: %s\n", YESNO(features->int_crt_support));
printf("\tIntegrated TV: %s\n", YESNO(features->int_tv_support));
+   printf("\tIntegrated EFP: %s\n", YESNO(features->int_efp_support));
+   printf("\tDP SSC enable: %s\n", YESNO(features->dp_ssc_enable));
+   if (features->dp_ssc_enable) {
+   if (IS_VALLEYVIEW(context->devid) || 
IS_CHERRYVIEW(context->devid) ||
+   IS_BROXTON(context->devid))
+   printf("\tSSC frequency: 100 MHz\n");
+   else if (HAS_PCH_SPLIT(context->devid))
+   printf("\tSSC frequency: %s\n", features->dp_ssc_freq ?
+  "100 MHz" : "120 MHz");
+   else
+   printf("\tSSC frequency: %s\n", features->dp_ssc_freq ?
+  "100 MHz" : "96 MHz");
+   }
+   printf("\tDP SSC dongle supported: %s\n", 

[Intel-gfx] [PATCH i-g-t 2/3] tools/intel_bios_reader: Dump out more information from the child device structure

[ville . syrjala]

From: Ville Syrjälä 

Signed-off-by: Ville Syrjälä 
---
 tools/intel_bios.h| 51 ++-
 tools/intel_bios_reader.c | 69 ++-
 2 files changed, 107 insertions(+), 13 deletions(-)

diff --git a/tools/intel_bios.h b/tools/intel_bios.h
index c4632da336d9..ac8c8650272d 100644
--- a/tools/intel_bios.h
+++ b/tools/intel_bios.h
@@ -272,18 +272,55 @@ struct child_device_config {
 struct efp_child_device_config {
uint16_t handle;
uint16_t device_type;
-   uint8_t skip1[12];
+   uint16_t device_class;
+   uint8_t i2c_speed;
+   uint8_t dp_onboard_redriver; /* 158 */
+   uint8_t dp_ondock_redriver; /* 158 */
+   uint8_t hdmi_level_shifter_value:4; /* 169 */
+   uint8_t hdmi_max_data_rate:4; /* 204 */
+   uint16_t dtd_buf_ptr; /* 161 */
+   uint8_t edidless_efp:1; /* 161 */
+   uint8_t compression_enable:1; /* 198 */
+   uint8_t compression_method:1; /* 198 */
+   uint8_t ganged_edp:1; /* 202 */
+   uint8_t skip0:4;
+   uint8_t compression_structure_index:4; /* 198 */
+   uint8_t skip1:4;
+   uint8_t slave_port; /*  202 */
+   uint8_t skip2;
uint8_t port;
-   uint8_t skip2[2];
+   uint8_t i2c_pin; /* for add-in card */
+   uint8_t slave_addr; /* for add-in card */
uint8_t ddc_pin;
-   uint8_t skip3[3];
-   uint8_t docked_port;
+   uint16_t edid_ptr;
+   uint8_t dvo_config;
+   uint8_t efp_docked_port:1; /* 158 */
+   uint8_t lane_reversal:1; /* 184 */
+   uint8_t onboard_lspcon:1; /* 192 */
+   uint8_t iboost_enable:1; /* 196 */
+   uint8_t hpd_invert:1; /* BXT 196 */
+   uint8_t slip3:3;
uint8_t hdmi_compat:1;
-   uint8_t conn_info:3;
-   uint8_t skip4:4;
+   uint8_t dp_compat:1;
+   uint8_t tmds_compat:1;
+   uint8_t skip4:5;
uint8_t aux_chan;
uint8_t dongle_detect;
-   uint8_t skip5[6];
+   uint8_t pipe_cap:2;
+   uint8_t sdvo_stall:1; /* 158 */
+   uint8_t hpd_status:2;
+   uint8_t integrated_encoder:1;
+   uint8_t skip5:2;
+   uint8_t dvo_wiring;
+   uint8_t mipi_bridge_type; /* 171 */
+   uint16_t device_class_ext;
+   uint8_t dvo_function;
+   uint8_t dp_usb_type_c:1; /* 195 */
+   uint8_t skip6:7;
+   uint8_t dp_usb_type_c_2x_gpio_index; /* 195 */
+   uint16_t dp_usb_type_c_2x_gpio_pin; /* 195 */
+   uint8_t iboost_dp:4; /* 196 */
+   uint8_t iboost_hdmi:4; /* 196 */
 } __attribute__ ((packed));
 
 struct bdb_general_definitions {
diff --git a/tools/intel_bios_reader.c b/tools/intel_bios_reader.c
index 588cc2c36c7a..3aefe2b1aacf 100644
--- a/tools/intel_bios_reader.c
+++ b/tools/intel_bios_reader.c
@@ -421,15 +421,72 @@ static void dump_child_device(struct context *context,
printf("\t\tDevice type: 0x%04x (%s)\n", efp->device_type,
   child_device_type(efp->device_type));
dump_child_device_type_bits(efp->device_type);
-   printf("\t\tPort: 0x%02x (%s)\n", efp->port,
-  efp_port(efp->port));
+   printf("\t\tI2C speed: 0x%02x\n", efp->i2c_speed);
+   printf("\t\tDP onboard redriver: 0x%02x\n", 
efp->dp_onboard_redriver);
+   printf("\t\tDP ondock redriver: 0x%02x\n", 
efp->dp_ondock_redriver);
+   printf("\t\tHDMI max data rate: 0x%02x\n", 
efp->hdmi_max_data_rate);
+   printf("\t\tHDMI level shifter value: 0x%02x\n", 
efp->hdmi_level_shifter_value);
+   printf("\t\tOffset to DTD buffer for edidless EFP: 0x%02x\n", 
efp->dtd_buf_ptr);
+   printf("\t\tDual pipe ganged eDP: %s\n", 
YESNO(efp->ganged_edp));
+   printf("\t\tCompression method CPS: %s\n", 
YESNO(efp->compression_method));
+   printf("\t\tCompression enable: %s\n", 
YESNO(efp->compression_enable));
+   printf("\t\tEdidless EFP: %s\n", YESNO(efp->edidless_efp));
+   printf("\t\tCompression structure index: 0x%02x)\n", 
efp->compression_structure_index);
+   printf("\t\tSlave DDI port: 0x%02x (%s)\n", efp->slave_port, 
efp_port(efp->slave_port));
+   printf("\t\tAIM offset: %d\n", child->addin_offset);
+   printf("\t\tPort: 0x%02x (%s)\n", efp->port, 
efp_port(efp->port));
+   printf("\t\tAIM I2C pin: 0x%02x\n", efp->i2c_pin);
+   printf("\t\tAIM Slave address: 0x%02x\n", efp->slave_addr);
printf("\t\tDDC pin: 0x%02x\n", efp->ddc_pin);
-   printf("\t\tDock port: 0x%02x (%s)\n", efp->docked_port,
-  efp_port(efp->docked_port));
-   printf("\t\tHDMI compatible? %s\n", efp->hdmi_compat ? "Yes" : 
"No");
-   printf("\t\tInfo: %s\n", efp_conn(efp->conn_info));
+   printf("\t\tEDID buffer ptr: 0x%02x\n", 

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

[Ville Syrjälä]

On Tue, Jun 21, 2016 at 09:53:15AM -0400, James Bottomley wrote:
> On Mon, 2016-06-20 at 11:03 +0300, Jani Nikula wrote:
> > Cc: Ville
> > 
> > On Mon, 20 Jun 2016, James Bottomley <
> > james.bottom...@hansenpartnership.com> wrote:
> > > OK, my candidate bad commit is this one:
> > > 
> > > commit a05628195a0d9f3173dd9aa76f482aef692e46ee
> > > Author: Ville Syrjälä 
> > > Date:   Mon Apr 11 10:23:51 2016 +0300
> > > 
> > > drm/i915: Get panel_type from OpRegion panel details
> > > 
> > > After being more careful about waiting to identify flicker, this 
> > > one seems to be the one the bisect finds.  I'm now running v4.7-rc3
> > > with this one reverted and am currently seeing no flicker problems.
> > >   It is, however, early days because the flicker can hide for long 
> > > periods, so I 'll wait until Monday evening and a few reboots 
> > > before declaring victory.
> > 
> > If that turns out to be the bad commit, it doesn't really surprise 
> > me, and that in itself is depressing.
> 
> As far as I can tell, after running for a day with this reverted, this
> is the problem.  The flicker hasn't appeared with it reverted.  It's
> pretty noticeable with this commit included.

Hmm. The only difference I can see is low vs. normal vswing. Panel 0 has
low, panel 2 has normal. So either the VBT or opregion is telling utter
lies, or there's some other bug in our low vswing support.

To confirm it's really a vswing issue, you should be able to run with
i915.edp_vswing=2 without flickers on the broken kernel.

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

[Intel-gfx] ✗ Ro.CI.BAT: failure for Enable lspcon support for GEN9 devices (rev2)

[Patchwork]

== Series Details ==

Series: Enable lspcon support for GEN9 devices (rev2)
URL   : https://patchwork.freedesktop.org/series/8024/
State : failure

== Summary ==

Series 8024v2 Enable lspcon support for GEN9 devices
http://patchwork.freedesktop.org/api/1.0/series/8024/revisions/2/mbox

Test drv_module_reload_basic:
pass   -> DMESG-WARN (ro-hsw-i7-4770r)
pass   -> DMESG-WARN (ro-bdw-i7-5600u)
pass   -> DMESG-WARN (ro-bdw-i7-5557U)
pass   -> DMESG-WARN (ro-hsw-i3-4010u)
pass   -> DMESG-WARN (ro-bdw-i5-5250u)
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-a:
pass   -> FAIL   (fi-skl-i5-6260u)
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> SKIP   (ro-bdw-i5-5250u)
Subgroup suspend-read-crc-pipe-c:
dmesg-warn -> SKIP   (ro-bdw-i5-5250u)

fi-skl-i5-6260u  total:225  pass:199  dwarn:0   dfail:0   fail:3   skip:23 
fi-skl-i7-6700k  total:225  pass:186  dwarn:0   dfail:0   fail:2   skip:37 
fi-snb-i7-2600   total:225  pass:172  dwarn:0   dfail:0   fail:2   skip:51 
ro-bdw-i5-5250u  total:225  pass:196  dwarn:2   dfail:0   fail:0   skip:27 
ro-bdw-i7-5557U  total:225  pass:197  dwarn:1   dfail:0   fail:0   skip:27 
ro-bdw-i7-5600u  total:225  pass:184  dwarn:1   dfail:0   fail:0   skip:40 
ro-byt-n2820 total:225  pass:173  dwarn:0   dfail:0   fail:3   skip:49 
ro-hsw-i3-4010u  total:225  pass:189  dwarn:1   dfail:0   fail:0   skip:35 
ro-hsw-i7-4770r  total:225  pass:189  dwarn:1   dfail:0   fail:0   skip:35 
ro-ilk-i7-620lm  total:225  pass:150  dwarn:0   dfail:0   fail:1   skip:74 
ro-ilk1-i5-650   total:220  pass:150  dwarn:0   dfail:0   fail:1   skip:69 
ro-ivb-i7-3770   total:225  pass:181  dwarn:0   dfail:0   fail:0   skip:44 
ro-ivb2-i7-3770  total:225  pass:185  dwarn:0   dfail:0   fail:0   skip:40 
ro-skl3-i5-6260u total:225  pass:201  dwarn:1   dfail:0   fail:0   skip:23 
ro-snb-i7-2620M  total:225  pass:174  dwarn:0   dfail:0   fail:1   skip:50 
fi-hsw-i7-4770k failed to connect after reboot
fi-kbl-qkkr failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1258/

12ce3eec drm-intel-nightly: 2016y-06m-21d-14h-43m-47s UTC integration manifest
e600d56 drm/i915: Enable lspcon initialization
cede9a2 drm/i915: Parse VBT data for lspcon
72229b0 drm/i915: Add lspcon support for I915 driver
b9ee05e drm: Helper for lspcon in drm_dp_dual_mode

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

Re: [Intel-gfx] [PATCH 42/44] drm/i915: Defer enabling rc6 til after we submit the first batch/context

[Chris Wilson]

On Wed, Jun 15, 2016 at 01:18:27PM +0100, Chris Wilson wrote:
> Some hardware requires a valid render context before it can initiate
> rc6 power gating of the GPU; the default state of the GPU is not
> sufficient and may lead to undefined behaviour. The first execution of
> any batch will load the "golden render state", at which point it is safe
> to enable rc6. As we do not forcibly load the kernel context at resume,
> we have to hook into the batch submission to be sure that the render
> state is setup before enabling rc6.
> 
> However, since we don't enable powersaving until that first batch, we
> queued a delayed task in order to guarantee that the batch is indeed
> submitted.
> 
> v2: Rearrange intel_disable_gt_powersave() to match.
> v3: Apply user specified cur_freq (or idle_freq if not set).
> v4: Give in, and supply a delayed work to autoenable rc6
> 
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> Cc: Ville Syrjälä 

Mika, you complained about this, does this address your needs?
-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 41/44] drm/i915: Remove superfluous powersave work flushing

[Chris Wilson]

On Wed, Jun 15, 2016 at 01:18:26PM +0100, Chris Wilson wrote:
> Instead of flushing the outstanding enabling, remember the requested
> frequency to apply when the powersave work runs.
> 
> Signed-off-by: Chris Wilson 
> Cc: Ville Syrjälä 

Ping? Everything should be in place by this point that userspace should
only see the current value and be able to program their desired value to
take effect when next active (rather than force activity).
-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/guc: Remove one unnecessary variable

[Chris Wilson]

On Tue, Jun 21, 2016 at 03:02:57PM +0100, Tvrtko Ursulin wrote:
> 
> On 21/06/16 14:00, Chris Wilson wrote:
> >On Tue, Jun 21, 2016 at 01:48:23PM +0100, Tvrtko Ursulin wrote:
> >>From: Tvrtko Ursulin 
> >>
> >>No need for local struct drm_device * since dev_priv is the
> >>correct thing to pass in to NEEDS_WaRsDisableCoarsePowerGating
> >>anyway. Changed the macro definition for the latter to reflect
> >>that as well.
> >>
> >>Signed-off-by: Tvrtko Ursulin 
> >>Cc: Dave Gordon 
> >>---
> >>  drivers/gpu/drm/i915/i915_drv.h| 7 ---
> >>  drivers/gpu/drm/i915/i915_guc_submission.c | 3 +--
> >>  2 files changed, 5 insertions(+), 5 deletions(-)
> >>
> >>diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> >>b/drivers/gpu/drm/i915/i915_drv.h
> >>index 48928227bdcc..3775d26ac573 100644
> >>--- a/drivers/gpu/drm/i915/i915_drv.h
> >>+++ b/drivers/gpu/drm/i915/i915_drv.h
> >>@@ -2788,9 +2788,10 @@ struct drm_i915_cmd_table {
> >>  #define HAS_BROKEN_CS_TLB(dev)(IS_I830(dev) || IS_845G(dev))
> >>
> >>  /* WaRsDisableCoarsePowerGating:skl,bxt */
> >>-#define NEEDS_WaRsDisableCoarsePowerGating(dev) (IS_BXT_REVID(dev, 0, 
> >>BXT_REVID_A1) || \
> >>-IS_SKL_GT3(dev) || \
> >>-IS_SKL_GT4(dev))
> >>+#define NEEDS_WaRsDisableCoarsePowerGating(dev_priv) 
> >>(IS_BXT_REVID(dev_priv, \
> >>+0, BXT_REVID_A1) || \
> >>+IS_SKL_GT3(dev_priv) || \
> >>+IS_SKL_GT4(dev_priv))
> >
> >#define NEEDS_WaRsDisableCoarsePowerGating(dev_priv) \
> > (IS_BXT_REVID(dev_priv, 0, BXT_REVID_A1) || \
> >  IS_SKL_GT3(dev_priv) ||
> >  IS_SKL_GT4(dev_priv))
> >
> >Other than that,
> >Reviewed-by: Chris Wilson 
> >
> >Just wondering if you fancy having a go at IS_SKL_GT(dev_priv, min, max)...
> 
> What do you have in mind?
> 
> This is a single call site for them BTW. And GCC amazingly does
> manage to merge the two GT tests on its own already. :)

#define GT(x) ((INTEL_DEVID(x) & 0xf0) >> 4)
IS_SKL_GT(dev, min, max) ({
int gt__ = GT(dev);
IS_SKYLAKE(dev) && gt__ >= (min) && gt__ < (min);
})

Give or take some more massaging.
-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 v2 1/4] drm: Helper for lspcon in drm_dp_dual_mode

[Shashank Sharma]

This patch adds lspcon support in dp_dual_mode helper.
lspcon is essentially a dp->hdmi dongle with dual personality.

LS mode: It works as a passive dongle, by level shifting DP++
signals to HDMI signals, in LS mode.
PCON mode: It works as a protocol converter active dongle
in pcon mode, by converting DP++ outputs to HDMI 2.0 outputs.

This patch adds support for lspcon detection and mode set
switch operations, as a dp dual mode dongle.

v2: Addressed review comments from Ville
- add adaptor id for lspcon devices (0x08), use it to identify lspcon
- change function names
  old: drm_lspcon_get_current_mode/drm_lspcon_change_mode
  new: drm_lspcon_get_mode/drm_lspcon_set_mode
- change drm_lspcon_get_mode type to int, to match
  drm_dp_dual_mode_get_tmds_output
- change 'err' to 'ret' to match the rest of the functions
- remove pointless typecasting during call to dual_mode_read
- fix the but while setting value of data, while writing lspcon mode
- fix indentation
- change mdelay(10) -> msleep(10)
- return ETIMEDOUT instead of EFAULT, when lspcon mode change times out
- Add an empty line to separate std regs macros and lspcon regs macros
  Indent bit definition

Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_dp_dual_mode_helper.c | 103 ++
 include/drm/drm_dp_dual_mode_helper.h |  25 
 2 files changed, 128 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c 
b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
index a7b2a75..404e715 100644
--- a/drivers/gpu/drm/drm_dp_dual_mode_helper.c
+++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
@@ -148,6 +148,14 @@ static bool is_type2_adaptor(uint8_t adaptor_id)
  DP_DUAL_MODE_REV_TYPE2);
 }
 
+bool is_lspcon_adaptor(const char hdmi_id[DP_DUAL_MODE_HDMI_ID_LEN],
+   const uint8_t adaptor_id)
+{
+   return is_hdmi_adaptor(hdmi_id) &&
+   (adaptor_id == (DP_DUAL_MODE_REV_TYPE2 |
+   DP_DUAL_MODE_TYPE_TYPE2 | DP_DUAL_MODE_TYPE_LSPCON));
+}
+
 /**
  * drm_dp_dual_mode_detect - Identify the DP dual mode adaptor
  * @adapter: I2C adapter for the DDC bus
@@ -203,6 +211,8 @@ enum drm_dp_dual_mode_type drm_dp_dual_mode_detect(struct 
i2c_adapter *adapter)
ret = drm_dp_dual_mode_read(adapter, DP_DUAL_MODE_ADAPTOR_ID,
_id, sizeof(adaptor_id));
if (ret == 0) {
+   if (is_lspcon_adaptor(hdmi_id, adaptor_id))
+   return DRM_DP_DUAL_MODE_LSPCON;
if (is_type2_adaptor(adaptor_id)) {
if (is_hdmi_adaptor(hdmi_id))
return DRM_DP_DUAL_MODE_TYPE2_HDMI;
@@ -364,3 +374,96 @@ const char *drm_dp_get_dual_mode_type_name(enum 
drm_dp_dual_mode_type type)
}
 }
 EXPORT_SYMBOL(drm_dp_get_dual_mode_type_name);
+
+/**
+ * drm_lspcon_get_current_mode: Get LSPCON's current mode of operation by
+ * by reading offset (0x80, 0x41)
+ * @i2c_adapter: I2C-over-aux adapter
+ * @current_mode: out vaiable, current lspcon mode of operation
+ *
+ * Returns:
+ * 0 on success, sets the current_mode value to appropriate mode
+ * -error on failure
+ */
+int drm_lspcon_get_mode(struct i2c_adapter *adapter,
+   enum drm_lspcon_mode *current_mode)
+{
+   u8 data;
+   int ret = 0;
+
+   if (!current_mode) {
+   DRM_ERROR("NULL input\n");
+   return -EINVAL;
+   }
+
+   /* Read Status: i2c over aux */
+   ret = drm_dp_dual_mode_read(adapter, DP_DUAL_MODE_LSPCON_CURRENT_MODE,
+   (void *), sizeof(data));
+   if (ret < 0) {
+   DRM_ERROR("LSPCON read(0x80, 0x41) failed\n");
+   return -EFAULT;
+   }
+
+   if (data & DP_DUAL_MODE_LSPCON_MODE_MASK)
+   *current_mode = DRM_LSPCON_MODE_PCON;
+   else
+   *current_mode = DRM_LSPCON_MODE_LS;
+   return 0;
+}
+EXPORT_SYMBOL(drm_lspcon_get_mode);
+
+/**
+ * drm_lspcon_change_mode: Change LSPCON's mode of operation by
+ * by writing offset (0x80, 0x40)
+ * @i2c_adapter: I2C-over-aux adapter
+ * @reqd_mode: required mode of operation
+ *
+ * Returns:
+ * 0 on success, -error on failure/timeout
+ */
+int drm_lspcon_set_mode(struct i2c_adapter *adapter,
+   enum drm_lspcon_mode reqd_mode)
+{
+   u8 data = 0;
+   int ret;
+   int time_out = 200;
+   enum drm_lspcon_mode changed_mode;
+
+   if (reqd_mode == DRM_LSPCON_MODE_PCON)
+   data = DP_DUAL_MODE_LSPCON_MODE_MASK;
+
+   /* Change mode */
+   ret = drm_dp_dual_mode_write(adapter, DP_DUAL_MODE_LSPCON_MODE_CHANGE,
+   , sizeof(data));
+   if (ret < 0) {
+   DRM_ERROR("LSPCON mode change failed\n");
+   return ret;
+   }
+
+   /*
+ * Confirm mode change by reading the status bit.
+ * Sometimes, it takes a while to change the mode,
+ * so wait and retry until time 

Re: [Intel-gfx] ✗ Ro.CI.BAT: warning for drm/i915/guc: Remove one unnecessary variable (rev2)

[Tvrtko Ursulin]

On 21/06/16 15:41, Patchwork wrote:

== Series Details ==

Series: drm/i915/guc: Remove one unnecessary variable (rev2)
URL   : https://patchwork.freedesktop.org/series/8995/
State : warning

== Summary ==

Series 8995v2 drm/i915/guc: Remove one unnecessary variable
http://patchwork.freedesktop.org/api/1.0/series/8995/revisions/2/mbox

Test kms_pipe_crc_basic:
 Subgroup suspend-read-crc-pipe-a:
 skip   -> DMESG-WARN (ro-bdw-i5-5250u)
 Subgroup suspend-read-crc-pipe-b:
 skip   -> DMESG-WARN (ro-bdw-i5-5250u)


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


fi-hsw-i7-4770k  total:225  pass:192  dwarn:0   dfail:0   fail:2   skip:31
fi-kbl-qkkr  total:225  pass:158  dwarn:29  dfail:0   fail:2   skip:36
fi-skl-i5-6260u  total:225  pass:200  dwarn:0   dfail:0   fail:2   skip:23
fi-snb-i7-2600   total:225  pass:172  dwarn:0   dfail:0   fail:2   skip:51
ro-bdw-i5-5250u  total:225  pass:197  dwarn:3   dfail:0   fail:0   skip:25
ro-bdw-i7-5557U  total:225  pass:198  dwarn:0   dfail:0   fail:0   skip:27
ro-bdw-i7-5600u  total:225  pass:185  dwarn:0   dfail:0   fail:0   skip:40
ro-byt-n2820 total:225  pass:173  dwarn:0   dfail:0   fail:3   skip:49
ro-hsw-i3-4010u  total:225  pass:190  dwarn:0   dfail:0   fail:0   skip:35
ro-hsw-i7-4770r  total:225  pass:190  dwarn:0   dfail:0   fail:0   skip:35
ro-ilk-i7-620lm  total:225  pass:150  dwarn:0   dfail:0   fail:1   skip:74
ro-ilk1-i5-650   total:220  pass:150  dwarn:0   dfail:0   fail:1   skip:69
ro-ivb-i7-3770   total:225  pass:181  dwarn:0   dfail:0   fail:0   skip:44
ro-ivb2-i7-3770  total:225  pass:185  dwarn:0   dfail:0   fail:0   skip:40
ro-skl3-i5-6260u total:225  pass:201  dwarn:1   dfail:0   fail:0   skip:23
ro-snb-i7-2620M  total:225  pass:174  dwarn:0   dfail:0   fail:1   skip:50
fi-skl-i7-6700k failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1257/

9d436e8 drm-intel-nightly: 2016y-06m-21d-13h-57m-22s UTC integration manifest
05a0233 drm/i915/guc: Remove one unnecessary variable


Merged to dinq, thanks for the review!

Regards,

Tvrtko


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

[Intel-gfx] [PATCH v2 4/4] drm/i915: Enable lspcon initialization

[Shashank Sharma]

This patch adds initialization code for lspcon.
What we are doing here is:
- Check if lspcon is configured in VBT for this port
- If lspcon is configured, initialize it and configure it
  as DP port.

V2: Addressed Ville's review comments:
- Not adding AVI IF functions for LSPCON display now.
  This part will be added once the dig_port level AVI-IF series
  gets merged.

Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/i915/intel_ddi.c | 29 -
 1 file changed, 28 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index ad3b0ee..208a1ff 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2323,7 +2323,7 @@ void intel_ddi_init(struct drm_device *dev, enum port 
port)
struct intel_digital_port *intel_dig_port;
struct intel_encoder *intel_encoder;
struct drm_encoder *encoder;
-   bool init_hdmi, init_dp;
+   bool init_hdmi, init_dp, init_lspcon = false;
int max_lanes;
 
if (I915_READ(DDI_BUF_CTL(PORT_A)) & DDI_A_4_LANES) {
@@ -2355,6 +2355,19 @@ void intel_ddi_init(struct drm_device *dev, enum port 
port)
init_hdmi = (dev_priv->vbt.ddi_port_info[port].supports_dvi ||
 dev_priv->vbt.ddi_port_info[port].supports_hdmi);
init_dp = dev_priv->vbt.ddi_port_info[port].supports_dp;
+
+   if (intel_bios_is_lspcon_present(dev_priv, port)) {
+   /*
+* Lspcon device needs to be driven with DP connector
+* with special detection sequence. So make sure DP
+* is initialized before lspcon.
+*/
+   init_dp = true;
+   init_lspcon = true;
+   init_hdmi = false;
+   DRM_DEBUG_KMS("VBT says port %c has lspcon\n", port_name(port));
+   }
+
if (!init_dp && !init_hdmi) {
DRM_DEBUG_KMS("VBT says port %c is not DVI/HDMI/DP compatible, 
respect it\n",
  port_name(port));
@@ -2430,6 +2443,20 @@ void intel_ddi_init(struct drm_device *dev, enum port 
port)
goto err;
}
 
+   if (init_lspcon) {
+   if (lspcon_init(intel_dig_port))
+   /* TODO: handle hdmi info frame part */
+   DRM_DEBUG_KMS("LSPCON init success on port %c\n",
+   port_name(port));
+   else
+   /*
+* LSPCON init faied, but DP init was success, so
+* lets try to drive as DP++ port.
+*/
+   DRM_ERROR("LSPCON init failed on port %c\n",
+   port_name(port));
+   }
+
return;
 
 err:
-- 
1.9.1

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

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

[Shashank Sharma]

This patch adds a new file, to accommodate lspcon support
for I915 driver. These functions probe, detect, initialize
and configure an on-board lspcon device during the driver
init time.

Also, this patch adds a small structure for lspcon device,
which will provide the runtime status of the device.

V2: addressed ville's review comments
- Clean the leftover macros from previous patch set

Signed-off-by: Shashank Sharma 
Signed-off-by: Akashdeep Sharma 
---
 drivers/gpu/drm/i915/Makefile   |   1 +
 drivers/gpu/drm/i915/intel_drv.h|  13 +++-
 drivers/gpu/drm/i915/intel_lspcon.c | 145 
 3 files changed, 158 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/i915/intel_lspcon.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 276abf1..d40ff7d 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -93,6 +93,7 @@ i915-y += dvo_ch7017.o \
  intel_dvo.o \
  intel_hdmi.o \
  intel_i2c.o \
+ intel_lspcon.o \
  intel_lvds.o \
  intel_panel.o \
  intel_sdvo.o \
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 7d0e071..4e49c16 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -894,12 +894,19 @@ struct intel_dp {
bool compliance_test_active;
 };
 
+struct intel_lspcon {
+   bool active;
+   enum drm_lspcon_mode mode_of_op;
+   struct drm_dp_aux *aux;
+};
+
 struct intel_digital_port {
struct intel_encoder base;
enum port port;
u32 saved_port_bits;
struct intel_dp dp;
struct intel_hdmi hdmi;
+   struct intel_lspcon lspcon;
enum irqreturn (*hpd_pulse)(struct intel_digital_port *, bool);
bool release_cl2_override;
uint8_t max_lanes;
@@ -1450,7 +1457,6 @@ bool intel_hdmi_compute_config(struct intel_encoder 
*encoder,
   struct intel_crtc_state *pipe_config);
 void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi *hdmi, bool enable);
 
-
 /* intel_lvds.c */
 void intel_lvds_init(struct drm_device *dev);
 bool intel_is_dual_link_lvds(struct drm_device *dev);
@@ -1745,4 +1751,9 @@ int intel_color_check(struct drm_crtc *crtc, struct 
drm_crtc_state *state);
 void intel_color_set_csc(struct drm_crtc_state *crtc_state);
 void intel_color_load_luts(struct drm_crtc_state *crtc_state);
 
+/* intel_lspcon.c */
+bool lspcon_init(struct intel_digital_port *intel_dig_port);
+enum drm_connector_status
+lspcon_ls_mode_detect(struct drm_connector *connector, bool force);
+bool is_lspcon_active(struct intel_digital_port *dig_port);
 #endif /* __INTEL_DRV_H__ */
diff --git a/drivers/gpu/drm/i915/intel_lspcon.c 
b/drivers/gpu/drm/i915/intel_lspcon.c
new file mode 100644
index 000..fdeff71
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_lspcon.c
@@ -0,0 +1,145 @@
+/*
+ * Copyright © 2016 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * 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 
+#include 
+#include 
+#include "intel_drv.h"
+
+bool is_lspcon_active(struct intel_digital_port *dig_port)
+{
+   return dig_port->lspcon.active;
+}
+
+enum drm_lspcon_mode lspcon_get_current_mode(struct intel_lspcon *lspcon)
+{
+   enum drm_lspcon_mode current_mode = DRM_LSPCON_MODE_INVALID;
+   struct i2c_adapter *adapter = >aux->ddc;
+
+   if (drm_lspcon_get_mode(adapter, _mode))
+   DRM_ERROR("Error reading LSPCON mode\n");
+   else
+   DRM_DEBUG_KMS("Current LSPCON mode %s\n",
+   current_mode == DRM_LSPCON_MODE_PCON ? "PCON" : "LS");
+   return current_mode;
+}
+
+int lspcon_change_mode(struct intel_lspcon *lspcon,
+   enum drm_lspcon_mode mode, bool force)
+{
+   int err;
+   enum drm_lspcon_mode 

[Intel-gfx] [PATCH v2 3/4] drm/i915: Parse VBT data for lspcon

[Shashank Sharma]

Many GEN9 boards come with on-board lspcon cards.
Fot these boards, VBT configuration should properly point out
if a particular port contains lspcon device, so that driver can
initialize it properly.

This patch adds a utility function, which checks the VBT flag
for lspcon bit, and tells us if a port is configured to have a
lspcon device or not.

V2: Fixed review comments from Ville
- Do not forget PORT_D while checking lspcon for GEN9

Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/i915/i915_drv.h   |  3 +++
 drivers/gpu/drm/i915/intel_bios.c | 49 +++
 2 files changed, 52 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 25ebe46..3719b81 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3671,6 +3671,9 @@ bool intel_bios_is_port_dp_dual_mode(struct 
drm_i915_private *dev_priv, enum por
 bool intel_bios_is_dsi_present(struct drm_i915_private *dev_priv, enum port 
*port);
 bool intel_bios_is_port_hpd_inverted(struct drm_i915_private *dev_priv,
 enum port port);
+bool intel_bios_is_lspcon_present(struct drm_i915_private *dev_priv,
+   enum port port);
+
 
 /* intel_opregion.c */
 #ifdef CONFIG_ACPI
diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index da5ed4a..2b00c89 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1759,3 +1759,52 @@ intel_bios_is_port_hpd_inverted(struct drm_i915_private 
*dev_priv,
 
return false;
 }
+
+/**
+ * intel_bios_is_lspcon_present - if LSPCON is attached on %port
+ * @dev_priv:  i915 device instance
+ * @port:  port to check
+ *
+ * Return true if LSPCON is present on this port
+ */
+bool
+intel_bios_is_lspcon_present(struct drm_i915_private *dev_priv,
+   enum port port)
+{
+   int i;
+
+   if (WARN_ON_ONCE(!IS_GEN9(dev_priv)))
+   return false;
+
+   for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
+   if (!dev_priv->vbt.child_dev[i].common.lspcon)
+   continue;
+
+   switch (dev_priv->vbt.child_dev[i].common.dvo_port) {
+   case DVO_PORT_DPA:
+   case DVO_PORT_HDMIA:
+   if (port == PORT_A)
+   return true;
+   break;
+   case DVO_PORT_DPB:
+   case DVO_PORT_HDMIB:
+   if (port == PORT_B)
+   return true;
+   break;
+   case DVO_PORT_DPC:
+   case DVO_PORT_HDMIC:
+   if (port == PORT_C)
+   return true;
+   break;
+   case DVO_PORT_DPD:
+   case DVO_PORT_HDMID:
+   if (port == PORT_D)
+   return true;
+   break;
+   default:
+   break;
+   }
+   }
+
+   return false;
+}
-- 
1.9.1

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

[Intel-gfx] [PATCH v2 0/4] Enable lspcon support for GEN9 devices

[Shashank Sharma]

LSPCON is essencially a dp++->hdmi adaptor with dual mode of operation.

These modes are:
- Level Shifter mode: In LS mode, this device works as a type2 dp->hdmi
passive dongle, which steps up DP++ output to appropriate HDMI 1.4 signal.
This mode doesn't do any conversion at the protocol level.

- Protocol Converter mode: In PCON mode, this device acts as an
active DP++->HDMI 2.0 dongle, which converts the DP++ output to
compatible HDMI 2.0 output. In PCON mode, lspcon can support 4k@60
outputs, using DP HBR2 mode.

Many of Intel GEN9 devices come with in-built lspcon card
in motherboartd down mode. This patch series adds support for
lspcon devices in I915 driver.

While unit-testing this code, I was able to see a 4k@60 modeset with:
- BXT-T board
- Single HDMI 4k@60 display (ACER S)
- Ubuntu 14.04 desktop

V2: Worked on review comments from Ville
- In general, Ville suggested not to use the dual personality of
  DDI to drive lspcon, so this patch set drives it just as DP++ display.
  There is no separate detection for lspcon (hpd_pulse is good enough), and
  its being driven as a DP display with special initialization and EDID
  read sequence. To be able to do this, we driving lspcon in PCON mode only,
  where it can serve both HDMI1.3/HDMI1.4 sinks as well as 4k@60 capable
  HDMI 2.0 sinks. So compared to previous series, there is one patch less,
  as we have dropped lspcon detection patch.

Shashank Sharma (4):
  drm: Helper for lspcon in drm_dp_dual_mode
  drm/i915: Add lspcon support for I915 driver
  drm/i915: Parse VBT data for lspcon
  drm/i915: Enable lspcon initialization

 drivers/gpu/drm/drm_dp_dual_mode_helper.c | 103 +
 drivers/gpu/drm/i915/Makefile |   1 +
 drivers/gpu/drm/i915/i915_drv.h   |   3 +
 drivers/gpu/drm/i915/intel_bios.c |  49 ++
 drivers/gpu/drm/i915/intel_ddi.c  |  29 +-
 drivers/gpu/drm/i915/intel_drv.h  |  13 ++-
 drivers/gpu/drm/i915/intel_lspcon.c   | 145 ++
 include/drm/drm_dp_dual_mode_helper.h |  25 ++
 8 files changed, 366 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_lspcon.c

-- 
1.9.1

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

Re: [Intel-gfx] i915 driver on Minnow board - 1920x1200 resolution not working

[Jani Nikula]

On Tue, 21 Jun 2016, vinoth eswaran  wrote:
> On Tue, Jun 21, 2016 at 12:54 PM, Jani Nikula
>  wrote:
>> On Tue, 21 Jun 2016, vinoth eswaran  wrote:
>>> On Tue, Jun 21, 2016 at 11:35 AM, Jani Nikula
>>>  wrote:
 On Tue, 21 Jun 2016, vinoth eswaran  wrote:
> On Tue, Jun 21, 2016 at 10:17 AM, Jani Nikula
>  wrote:
>> On Tue, 21 Jun 2016, vinoth eswaran  wrote:
>>> Hello,
>>>
>>> I am currently working on an embedded project using Minnowboard max. I
>>> have builded a customized Linux kernel-v4.4 and using u-boot (latest
>>> version) as Boot loader.
>>>
>>> The VESA driver in the u-boot takes more time to initialize,so I have
>>> disabled it. I am passing the kernel parameters "video=" to enable the
>>> HDMI port to which a monitor is connected.
>>
>> Is is a DVI display?
>Its an LED Monitor - LG 24EB23.
> The monitor supports the HD resolution.

 How do you connect the display? Is it HDMI directly or using the DVI
 connector?

>>>Sorry initially I got the question wrongly.
>>> Micro HDMI connector to the board and then HDMI-DVI cable to connect
>>> to the monitor.
>>
>> Single link DVI is limited to 165 Mhz. It *might* work with CVT and
>> reduced blanking. Please try video=HDMI-A-1:1920x1200@60RMD as the mode.
>>
>> I'm surprised the display doesn't report that via EDID to begin with;
>> what does it do without the video parameter on the command line?
>
> The display is not coming up now. Also without no video parameter,
> the display is not coming up.
> I checked the status of card-0* in /sys/class/drm all the three
> connectors are listed as disconnected.
>
> I have attached the drm driver logs for your reference.

Gets too noisy to debug here. Please file a bug at [1].

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] ✗ Ro.CI.BAT: warning for drm/i915/guc: Remove one unnecessary variable (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/guc: Remove one unnecessary variable (rev2)
URL   : https://patchwork.freedesktop.org/series/8995/
State : warning

== Summary ==

Series 8995v2 drm/i915/guc: Remove one unnecessary variable
http://patchwork.freedesktop.org/api/1.0/series/8995/revisions/2/mbox

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
skip   -> DMESG-WARN (ro-bdw-i5-5250u)
Subgroup suspend-read-crc-pipe-b:
skip   -> DMESG-WARN (ro-bdw-i5-5250u)

fi-hsw-i7-4770k  total:225  pass:192  dwarn:0   dfail:0   fail:2   skip:31 
fi-kbl-qkkr  total:225  pass:158  dwarn:29  dfail:0   fail:2   skip:36 
fi-skl-i5-6260u  total:225  pass:200  dwarn:0   dfail:0   fail:2   skip:23 
fi-snb-i7-2600   total:225  pass:172  dwarn:0   dfail:0   fail:2   skip:51 
ro-bdw-i5-5250u  total:225  pass:197  dwarn:3   dfail:0   fail:0   skip:25 
ro-bdw-i7-5557U  total:225  pass:198  dwarn:0   dfail:0   fail:0   skip:27 
ro-bdw-i7-5600u  total:225  pass:185  dwarn:0   dfail:0   fail:0   skip:40 
ro-byt-n2820 total:225  pass:173  dwarn:0   dfail:0   fail:3   skip:49 
ro-hsw-i3-4010u  total:225  pass:190  dwarn:0   dfail:0   fail:0   skip:35 
ro-hsw-i7-4770r  total:225  pass:190  dwarn:0   dfail:0   fail:0   skip:35 
ro-ilk-i7-620lm  total:225  pass:150  dwarn:0   dfail:0   fail:1   skip:74 
ro-ilk1-i5-650   total:220  pass:150  dwarn:0   dfail:0   fail:1   skip:69 
ro-ivb-i7-3770   total:225  pass:181  dwarn:0   dfail:0   fail:0   skip:44 
ro-ivb2-i7-3770  total:225  pass:185  dwarn:0   dfail:0   fail:0   skip:40 
ro-skl3-i5-6260u total:225  pass:201  dwarn:1   dfail:0   fail:0   skip:23 
ro-snb-i7-2620M  total:225  pass:174  dwarn:0   dfail:0   fail:1   skip:50 
fi-skl-i7-6700k failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1257/

9d436e8 drm-intel-nightly: 2016y-06m-21d-13h-57m-22s UTC integration manifest
05a0233 drm/i915/guc: Remove one unnecessary variable

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

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Use atomic commits for legacy page_flips

[Daniel Vetter]

Adding Maarten/Daniela since I'm going on vacation.
-Daniel

On Mon, Jun 20, 2016 at 8:30 PM, Matthew Auld
 wrote:
> I seem to be hitting some issues with this, at least in gnome-shell
> which I bisected to this commit. Somewhat hard to describe but the
> background window or desktop is partiality and intermittently drawn,
> almost like a flicker onto the foreground window, title-bar etc.
> typically during any kind of transition animation, like switching
> windows, though sometimes just at random. Any ideas, I take it you
> haven't seen anything like this while testing?



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

[Intel-gfx] [PATCH v2] drm/i915/guc: Remove one unnecessary variable

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

No need for local struct drm_device * since dev_priv is the
correct thing to pass in to NEEDS_WaRsDisableCoarsePowerGating
anyway. Changed the macro definition for the latter to reflect
that as well.

v2: Alignment bikeshed.

Signed-off-by: Tvrtko Ursulin 
Cc: Dave Gordon 
Reviewed-by: Chris Wilson 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_drv.h| 7 ---
 drivers/gpu/drm/i915/i915_guc_submission.c | 3 +--
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 48928227bdcc..99e7a4fdcbe0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2788,9 +2788,10 @@ struct drm_i915_cmd_table {
 #define HAS_BROKEN_CS_TLB(dev) (IS_I830(dev) || IS_845G(dev))
 
 /* WaRsDisableCoarsePowerGating:skl,bxt */
-#define NEEDS_WaRsDisableCoarsePowerGating(dev) (IS_BXT_REVID(dev, 0, 
BXT_REVID_A1) || \
-IS_SKL_GT3(dev) || \
-IS_SKL_GT4(dev))
+#define NEEDS_WaRsDisableCoarsePowerGating(dev_priv) \
+   (IS_BXT_REVID(dev_priv, 0, BXT_REVID_A1) || \
+IS_SKL_GT3(dev_priv) || \
+IS_SKL_GT4(dev_priv))
 
 /*
  * dp aux and gmbus irq on gen4 seems to be able to generate legacy interrupts
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 22a55ac4e51c..643bc3b2e3b8 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -153,12 +153,11 @@ static int host2guc_sample_forcewake(struct intel_guc 
*guc,
 struct i915_guc_client *client)
 {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
-   struct drm_device *dev = dev_priv->dev;
u32 data[2];
 
data[0] = HOST2GUC_ACTION_SAMPLE_FORCEWAKE;
/* WaRsDisableCoarsePowerGating:skl,bxt */
-   if (!intel_enable_rc6() || NEEDS_WaRsDisableCoarsePowerGating(dev))
+   if (!intel_enable_rc6() || NEEDS_WaRsDisableCoarsePowerGating(dev_priv))
data[1] = 0;
else
/* bit 0 and 1 are for Render and Media domain separately */
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH] drm/i915/guc: Remove one unnecessary variable

[Tvrtko Ursulin]

On 21/06/16 14:00, Chris Wilson wrote:

On Tue, Jun 21, 2016 at 01:48:23PM +0100, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

No need for local struct drm_device * since dev_priv is the
correct thing to pass in to NEEDS_WaRsDisableCoarsePowerGating
anyway. Changed the macro definition for the latter to reflect
that as well.

Signed-off-by: Tvrtko Ursulin 
Cc: Dave Gordon 
---
  drivers/gpu/drm/i915/i915_drv.h| 7 ---
  drivers/gpu/drm/i915/i915_guc_submission.c | 3 +--
  2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 48928227bdcc..3775d26ac573 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2788,9 +2788,10 @@ struct drm_i915_cmd_table {
  #define HAS_BROKEN_CS_TLB(dev)(IS_I830(dev) || IS_845G(dev))

  /* WaRsDisableCoarsePowerGating:skl,bxt */
-#define NEEDS_WaRsDisableCoarsePowerGating(dev) (IS_BXT_REVID(dev, 0, 
BXT_REVID_A1) || \
-IS_SKL_GT3(dev) || \
-IS_SKL_GT4(dev))
+#define NEEDS_WaRsDisableCoarsePowerGating(dev_priv) (IS_BXT_REVID(dev_priv, \
+0, BXT_REVID_A1) || \
+IS_SKL_GT3(dev_priv) || \
+IS_SKL_GT4(dev_priv))


#define NEEDS_WaRsDisableCoarsePowerGating(dev_priv) \
(IS_BXT_REVID(dev_priv, 0, BXT_REVID_A1) || \
 IS_SKL_GT3(dev_priv) ||
 IS_SKL_GT4(dev_priv))

Other than that,
Reviewed-by: Chris Wilson 

Just wondering if you fancy having a go at IS_SKL_GT(dev_priv, min, max)...


What do you have in mind?

This is a single call site for them BTW. And GCC amazingly does manage 
to merge the two GT tests on its own already. :)


Regards,

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

Re: [Intel-gfx] [RFC i-g-t v3 08/13] lib/stubs: Add stubs for intel_bufmgr.

[Emil Velikov]

On 21 June 2016 at 14:41, Emil Velikov  wrote:
> On 21 June 2016 at 13:50, Marius Vlad  wrote:
>> On Mon, Jun 20, 2016 at 03:52:35PM +0100, Emil Velikov wrote:
>>> Hi Rob,
>>>
>>> A couple of nitpicks and a case of missing git add :-)
>>>
>>> On 15 June 2016 at 10:51,   wrote:
>>>
>>> > +if HAVE_LIBDRM_INTEL
>>> > +else
>>> > +libintel_tools_la_SOURCES +=   \
>>> > +stubs/drm/intel_bufmgr.c   \
>>> > +stubs/drm/intel_bufmgr.h
>>> > +endif
>>> > +
>>> I believe I mentioned if before - please use the following construct
>>>
>>> if !HAVE_LIBDRM_INTEL
>>> libintel_tools_la_SOURCES +=   \
>>> stubs/drm/intel_bufmgr.c   \
>>> stubs/drm/intel_bufmgr.h
>>> endif
>>>
>>> >  AM_CPPFLAGS = -I$(top_srcdir)
>>> >  AM_CFLAGS = $(CWARNFLAGS) $(DRM_CFLAGS) $(PCIACCESS_CFLAGS) 
>>> > $(LIBUNWIND_CFLAGS) $(DEBUG_CFLAGS) \
>>> > -DIGT_SRCDIR=\""$(abs_top_srcdir)/tests"\" \
>>> > diff --git a/lib/stubs/drm/README b/lib/stubs/drm/README
>>> > new file mode 100644
>>> > index 000..dec6a1d
>>> > --- /dev/null
>>> > +++ b/lib/stubs/drm/README
>>> > @@ -0,0 +1,4 @@
>>> > +intel_bufmgr.h is a copy the file provided in libdrm 
>>> > (intel/intel_bufmgr.h).
>>> > +
>>> s/copy the file provided in/local copy of the file provided by/
>>>
>>> Sadly that's not the case atm. There's a fair few changes in the local 
>>> 'copy'.
>>> Perhaps you forgot to git add ?
>>>
>>> > +Before releasing i-g-t a current copy of intel_bufmgr.h should be copied 
>>> > into
>>> > +this directory of i-g-t.
>>
>> Auch, but synchronizing this wouldn't be a nightmare? I mean stubs
>> might be added/removed in the future.
>>
> Maybe slightly annoying, but definitely not nightmare. As with any
> other library one _cannot_ remove API without bumping major (and/or
> changing the library name), so things should be fine on that regard.
> Guess one should stress that intel_bufmgr.h should be copied from the
> latest libdrm release and
[Fingers slipped]
... _not_ from git.

>
>>>
>>> Thinking about it... I'm not sure that the release manager will find
>>> this note here :-\
>>>
>>> Daniel V, Marius, do you guys have a tick-off list somewhere where
>>> this could be added ?
>>
>> README and NEWS. Don't know of any other.
>>
> Can I ask that you/Daniel can update those ? I'm afraid
>
... we'll likely make things more ambiguous that they need to be.

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

Re: [Intel-gfx] [RFC i-g-t v3 08/13] lib/stubs: Add stubs for intel_bufmgr.

[Emil Velikov]

On 21 June 2016 at 13:50, Marius Vlad  wrote:
> On Mon, Jun 20, 2016 at 03:52:35PM +0100, Emil Velikov wrote:
>> Hi Rob,
>>
>> A couple of nitpicks and a case of missing git add :-)
>>
>> On 15 June 2016 at 10:51,   wrote:
>>
>> > +if HAVE_LIBDRM_INTEL
>> > +else
>> > +libintel_tools_la_SOURCES +=   \
>> > +stubs/drm/intel_bufmgr.c   \
>> > +stubs/drm/intel_bufmgr.h
>> > +endif
>> > +
>> I believe I mentioned if before - please use the following construct
>>
>> if !HAVE_LIBDRM_INTEL
>> libintel_tools_la_SOURCES +=   \
>> stubs/drm/intel_bufmgr.c   \
>> stubs/drm/intel_bufmgr.h
>> endif
>>
>> >  AM_CPPFLAGS = -I$(top_srcdir)
>> >  AM_CFLAGS = $(CWARNFLAGS) $(DRM_CFLAGS) $(PCIACCESS_CFLAGS) 
>> > $(LIBUNWIND_CFLAGS) $(DEBUG_CFLAGS) \
>> > -DIGT_SRCDIR=\""$(abs_top_srcdir)/tests"\" \
>> > diff --git a/lib/stubs/drm/README b/lib/stubs/drm/README
>> > new file mode 100644
>> > index 000..dec6a1d
>> > --- /dev/null
>> > +++ b/lib/stubs/drm/README
>> > @@ -0,0 +1,4 @@
>> > +intel_bufmgr.h is a copy the file provided in libdrm 
>> > (intel/intel_bufmgr.h).
>> > +
>> s/copy the file provided in/local copy of the file provided by/
>>
>> Sadly that's not the case atm. There's a fair few changes in the local 
>> 'copy'.
>> Perhaps you forgot to git add ?
>>
>> > +Before releasing i-g-t a current copy of intel_bufmgr.h should be copied 
>> > into
>> > +this directory of i-g-t.
>
> Auch, but synchronizing this wouldn't be a nightmare? I mean stubs
> might be added/removed in the future.
>
Maybe slightly annoying, but definitely not nightmare. As with any
other library one _cannot_ remove API without bumping major (and/or
changing the library name), so things should be fine on that regard.
Guess one should stress that intel_bufmgr.h should be copied from the
latest libdrm release and

>>
>> Thinking about it... I'm not sure that the release manager will find
>> this note here :-\
>>
>> Daniel V, Marius, do you guys have a tick-off list somewhere where
>> this could be added ?
>
> README and NEWS. Don't know of any other.
>
Can I ask that you/Daniel can update those ? I'm afraid

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

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915/guc: Remove one unnecessary variable

[Patchwork]

== Series Details ==

Series: drm/i915/guc: Remove one unnecessary variable
URL   : https://patchwork.freedesktop.org/series/8995/
State : failure

== Summary ==

Series 8995v1 drm/i915/guc: Remove one unnecessary variable
http://patchwork.freedesktop.org/api/1.0/series/8995/revisions/1/mbox

Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
pass   -> FAIL   (ro-bdw-i5-5250u)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
skip   -> DMESG-WARN (ro-bdw-i5-5250u)
pass   -> INCOMPLETE (fi-skl-i7-6700k)
Subgroup suspend-read-crc-pipe-c:
dmesg-warn -> SKIP   (ro-bdw-i5-5250u)
Test pm_rpm:
Subgroup basic-rte:
skip   -> PASS   (fi-skl-i5-6260u)

fi-hsw-i7-4770k  total:225  pass:192  dwarn:0   dfail:0   fail:2   skip:31 
fi-kbl-qkkr  total:225  pass:159  dwarn:28  dfail:0   fail:2   skip:36 
fi-skl-i5-6260u  total:225  pass:200  dwarn:0   dfail:0   fail:2   skip:23 
fi-skl-i7-6700k  total:188  pass:162  dwarn:0   dfail:0   fail:2   skip:23 
fi-snb-i7-2600   total:225  pass:172  dwarn:0   dfail:0   fail:2   skip:51 
ro-bdw-i5-5250u  total:225  pass:196  dwarn:2   dfail:0   fail:1   skip:26 
ro-bdw-i7-5557U  total:225  pass:198  dwarn:0   dfail:0   fail:0   skip:27 
ro-bdw-i7-5600u  total:225  pass:185  dwarn:0   dfail:0   fail:0   skip:40 
ro-byt-n2820 total:225  pass:173  dwarn:0   dfail:0   fail:3   skip:49 
ro-hsw-i3-4010u  total:225  pass:190  dwarn:0   dfail:0   fail:0   skip:35 
ro-hsw-i7-4770r  total:225  pass:190  dwarn:0   dfail:0   fail:0   skip:35 
ro-ilk-i7-620lm  total:225  pass:150  dwarn:0   dfail:0   fail:1   skip:74 
ro-ilk1-i5-650   total:220  pass:150  dwarn:0   dfail:0   fail:1   skip:69 
ro-ivb-i7-3770   total:225  pass:181  dwarn:0   dfail:0   fail:0   skip:44 
ro-ivb2-i7-3770  total:225  pass:185  dwarn:0   dfail:0   fail:0   skip:40 
ro-skl3-i5-6260u total:225  pass:201  dwarn:1   dfail:0   fail:0   skip:23 
ro-snb-i7-2620M  total:225  pass:174  dwarn:0   dfail:0   fail:1   skip:50 

Results at /archive/results/CI_IGT_test/RO_Patchwork_1256/

661e1d8 drm-intel-nightly: 2016y-06m-21d-12h-45m-27s UTC integration manifest
d3941b1 drm/i915/guc: Remove one unnecessary variable

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

Re: [Intel-gfx] [PATCH igt] igt: Add basic framework for GVT-g testing

[Chris Wilson]

On Tue, Jun 21, 2016 at 01:24:26PM +, Wang, Zhi A wrote:
> > +   while ((vtcon = readdir(dir))) {
> > +   int fd, len;
> > +
> > +   if (strncmp(vtcon->d_name, "vtcon", 5))
> > +   continue;
> > +
> > +   sprintf(buf, "%s/%s/name", path, vtcon->d_name);
> > +   fd = open(buf, O_RDONLY);
> > +   if (fd < 0)
> > +   continue;
> > +
> > +   len = read(fd, buf, sizeof(buf) - 1);
> Will i-g-t use SIGALRM in global test framework? If yes, maybe we should 
> check len == -1 && errno == -EINTR or set SA_RESTART in sigaction(SIGALRM).

Interrupts tend to be added on demand, If we are being thorough, then
yes we should do a readN / writeN here. (Not that I think either kernfs
here reports EINTR.)

> > +static void unload_i915(void)
> > +{
> > +   unbind_fbcon();
> > +   /* pkill alsact */
> > +
> 
> Is there any reason that we should care about alsact? Are you concerned about 
> sound card configuration tool will cause i915 unload failure? BTW I think 
> maybe it should be alsactl?

Yes, the sound driver can keep i915 loaded, so we need to kill anything
keeping the snd_hda_intel alive before we can (recursively) remove i915.
-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 6/8] drm/i915: Demidlayer driver loading

[Chris Wilson]

On Tue, Jun 21, 2016 at 03:27:02PM +0200, Daniel Vetter wrote:
> On Tue, Jun 21, 2016 at 09:53:46AM +0100, Chris Wilson wrote:
> > -int i915_driver_load(struct drm_device *dev, unsigned long flags)
> > +int i915_driver_load(struct pci_dev *pdev,
> > +const struct pci_device_id *ent,
> > +struct drm_driver *driver)
> >  {
> > struct drm_i915_private *dev_priv;
> > -   int ret = 0;
> > +   int ret;
> >  
> > +   ret = 0;
> > dev_priv = kzalloc(sizeof(*dev_priv), GFP_KERNEL);
> > -   if (dev_priv == NULL)
> > +   if (dev_priv)
> > +   ret = drm_dev_init(_priv->drm, driver, >dev);
> > +   if (ret) {
> 
> This ended up a bit too clever, will fail to spot the failure when
> dev_priv == NULL. I guess you wanted a ret = -ENOMEM up there.

Yup, and we should then return ret rather than return -ENOMEM.
Ta,
-Chris

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

Re: [Intel-gfx] [PATCH v3] drm/i915/fbc: FBC causes display flicker when VT-d is enabled on Skylake

[Daniel Vetter]

On Tue, Jun 21, 2016 at 08:25:27AM +0100, Chris Wilson wrote:
> Erratum SKL075: Display Flicker May Occur When Both VT-d And FBC Are Enabled
> 
> "Display flickering may occur when both FBC (Frame Buffer Compression)
> and VT - d (Intel® Virtualization Technology for Directed I/O) are enabled
> and in use by the display controller."
> 
> Ville found the w/a name in the database:
> WaFbcTurnOffFbcWhenHyperVisorIsUsed:skl
> 
> v2: Log when the quirk is applied.
> v3: Ensure i915.enable_fbc is false when !HAS_FBC()
> 
> Signed-off-by: Chris Wilson 
> Cc: Paulo Zanoni 
> Cc: Ville Syrjälä 

Do we know whether this helps on other machines too? I can imagine that
the additional lookup latency just plain wreaks havoc everywhere ...
-Daniel

> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  2 ++
>  drivers/gpu/drm/i915/intel_fbc.c | 19 +++
>  2 files changed, 21 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 89298d3ad94b..f1e9fd07d441 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2586,6 +2586,8 @@ struct drm_i915_cmd_table {
>  #define INTEL_GEN(p) (INTEL_INFO(p)->gen)
>  #define INTEL_DEVID(p)   (INTEL_INFO(p)->device_id)
>  
> +#define mkwrite_intel_info(p) ((struct intel_device_info *)INTEL_INFO(p))
> +
>  #define REVID_FOREVER0xff
>  #define INTEL_REVID(p)   (__I915__(p)->drm.pdev->revision)
>  
> diff --git a/drivers/gpu/drm/i915/intel_fbc.c 
> b/drivers/gpu/drm/i915/intel_fbc.c
> index ac26aa8be9d0..fd5865d80bec 100644
> --- a/drivers/gpu/drm/i915/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> @@ -1238,12 +1238,28 @@ static int intel_sanitize_fbc_option(struct 
> drm_i915_private *dev_priv)
>   if (i915.enable_fbc >= 0)
>   return !!i915.enable_fbc;
>  
> + if (!HAS_FBC(dev_priv))
> + return 0;
> +
>   if (IS_BROADWELL(dev_priv))
>   return 1;
>  
>   return 0;
>  }
>  
> +static bool need_fbc_wa(struct drm_i915_private *dev_priv)
> +{
> +#ifdef CONFIG_INTEL_IOMMU
> + /* WaFbcTurnOffFbcWhenHyperVisorIsUsed:skl */
> + if (intel_iommu_gfx_mapped && IS_SKYLAKE(dev_priv)) {
> + DRM_INFO("Disabling framebuffer compression (FBC) to prevent 
> screen flicker with VT-d enabled\n");
> + return true;
> + }
> +#endif
> +
> + return false;
> +}
> +
>  /**
>   * intel_fbc_init - Initialize FBC
>   * @dev_priv: the i915 device
> @@ -1261,6 +1277,9 @@ void intel_fbc_init(struct drm_i915_private *dev_priv)
>   fbc->active = false;
>   fbc->work.scheduled = false;
>  
> + if (need_fbc_wa(dev_priv))
> + mkwrite_intel_info(dev_priv)->has_fbc = false;
> +
>   i915.enable_fbc = intel_sanitize_fbc_option(dev_priv);
>   DRM_DEBUG_KMS("Sanitized enable_fbc value: %d\n", i915.enable_fbc);
>  
> -- 
> 2.8.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH 4/8] drm/i915: Move connector registration to driver registration

[Chris Wilson]

On Tue, Jun 21, 2016 at 03:18:12PM +0200, Daniel Vetter wrote:
> On Tue, Jun 21, 2016 at 09:53:44AM +0100, Chris Wilson wrote:
> > +void intel_modeset_register(struct drm_i915_private *dev_priv)
> > +{
> > +   drm_connector_register_all(dev_priv->dev);
> > +}
> > +
> > +void intel_modeset_unregister(struct drm_i915_private *dev_priv)
> > +{
> > +   drm_connector_unregister_all(dev_priv->dev);
> > +}
> 
> Given that this will all disappear again I wouldn't bother with the
> wrapper functions.

They exist to conform with the intel_modeset_phase(). I thought they
helped tell the story of how we are moving the phases around.
-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 8/8] drm/i915: Remove redundant drm_connector_register_all()

[Daniel Vetter]

On Tue, Jun 21, 2016 at 09:53:48AM +0100, Chris Wilson wrote:
> drm_connector_register_all() is now automatically called by
> drm_dev_register(), and so we no longer have to do so ourselves (via
> intel_modeset_register() after calling drm_dev_register()). Similarly
> for unregistering.
> 
> Signed-off-by: Chris Wilson 

Ok, they disappear again. Feel free to ignore my earlier comment. With the
other nitpicks fixed, on the entire series:

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/i915/i915_dma.c  |  2 --
>  drivers/gpu/drm/i915/i915_drv.h  |  2 --
>  drivers/gpu/drm/i915/intel_display.c | 10 --
>  3 files changed, 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index b6e7aab109d6..af77c18ee2de 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -1403,7 +1403,6 @@ static void i915_driver_register(struct 
> drm_i915_private *dev_priv)
>   if (drm_dev_register(dev, 0) == 0) {
>   i915_debugfs_register(dev_priv);
>   i915_setup_sysfs(dev);
> - intel_modeset_register(dev_priv);
>   } else
>   DRM_ERROR("Failed to register driver for userspace access!\n");
>  
> @@ -1440,7 +1439,6 @@ static void i915_driver_unregister(struct 
> drm_i915_private *dev_priv)
>   acpi_video_unregister();
>   intel_opregion_unregister(dev_priv);
>  
> - intel_modeset_unregister(dev_priv);
>   i915_teardown_sysfs(dev_priv->dev);
>   i915_debugfs_unregister(dev_priv);
>   drm_dev_unregister(dev_priv->dev);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 20a82b6a050d..ac4fc5e6f14f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3733,8 +3733,6 @@ extern void intel_modeset_init_hw(struct drm_device 
> *dev);
>  extern void intel_modeset_init(struct drm_device *dev);
>  extern void intel_modeset_gem_init(struct drm_device *dev);
>  extern void intel_modeset_cleanup(struct drm_device *dev);
> -extern void intel_modeset_register(struct drm_i915_private *dev_priv);
> -extern void intel_modeset_unregister(struct drm_i915_private *dev_priv);
>  extern int intel_connector_register(struct drm_connector *);
>  extern void intel_connector_unregister(struct drm_connector *);
>  extern int intel_modeset_vga_set_state(struct drm_device *dev, bool state);
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 1557b00836fe..254a5679954f 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -15546,16 +15546,6 @@ void intel_modeset_init_hw(struct drm_device *dev)
>   intel_enable_gt_powersave(dev_priv);
>  }
>  
> -void intel_modeset_register(struct drm_i915_private *dev_priv)
> -{
> - drm_connector_register_all(dev_priv->dev);
> -}
> -
> -void intel_modeset_unregister(struct drm_i915_private *dev_priv)
> -{
> - drm_connector_unregister_all(dev_priv->dev);
> -}
> -
>  /*
>   * Calculate what we think the watermarks should be for the state we've read
>   * out of the hardware and then immediately program those watermarks so that
> -- 
> 2.8.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH 6/8] drm/i915: Demidlayer driver loading

[Daniel Vetter]

On Tue, Jun 21, 2016 at 09:53:46AM +0100, Chris Wilson wrote:
> Take control over allocating, loading and registering the driver from the
> DRM midlayer by performing it manually from i915_pci_probe. This allows
> us to carefully control the order of when we setup the hardware vs when
> it becomes visible to third parties (including userspace). The current
> ordering makes the driver visible to userspace first (in order to
> coordinate with removed DRI1 userspace), but that ordering incurs risk.
> The risk increases as we strive for more asynchronous loading.
> 
> One side effect of controlling the allocation is that we can allocate
> both the drm_device + drm_i915_private in one block, the next step
> towards subclassing.
> 
> Unload is still left as before, a mix of midlayer and driver.
> 
> v2: After drm_dev_init(), we should call drm_dev_unref() so that we call
> drm_dev_release() and free everything from drm_dev_init().
> 
> Suggested-by: Daniel Vetter 
> Signed-off-by: Chris Wilson 
> Cc: Daniel Vetter 
> Cc: Ville Syrjälä 

A bit much s/dev/dev_priv/ conversion here for my taste, but meh. One real
issue spotted below.

> ---
>  drivers/gpu/drm/i915/i915_dma.c | 76 
> ++---
>  drivers/gpu/drm/i915/i915_drv.c |  3 +-
>  drivers/gpu/drm/i915/i915_drv.h |  6 +++-
>  3 files changed, 54 insertions(+), 31 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 91623874f9a3..0e43ad511833 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -1075,9 +1075,10 @@ static void i915_workqueues_cleanup(struct 
> drm_i915_private *dev_priv)
>   * function hooks not requiring accessing the device.
>   */
>  static int i915_driver_init_early(struct drm_i915_private *dev_priv,
> -   struct drm_device *dev,
> -   struct intel_device_info *info)
> +   const struct pci_device_id *ent)
>  {
> + const struct intel_device_info *match_info =
> + (struct intel_device_info *)ent->driver_data;
>   struct intel_device_info *device_info;
>   int ret = 0;
>  
> @@ -1086,8 +1087,8 @@ static int i915_driver_init_early(struct 
> drm_i915_private *dev_priv,
>  
>   /* Setup the write-once "constant" device info */
>   device_info = (struct intel_device_info *)_priv->info;
> - memcpy(device_info, info, sizeof(dev_priv->info));
> - device_info->device_id = dev->pdev->device;
> + memcpy(device_info, match_info, sizeof(*device_info));
> + device_info->device_id = dev_priv->drm.pdev->device;
>  
>   BUG_ON(device_info->gen > sizeof(device_info->gen_mask) * 
> BITS_PER_BYTE);
>   device_info->gen_mask = BIT(device_info->gen - 1);
> @@ -1113,18 +1114,18 @@ static int i915_driver_init_early(struct 
> drm_i915_private *dev_priv,
>   goto err_workqueues;
>  
>   /* This must be called before any calls to HAS_PCH_* */
> - intel_detect_pch(dev);
> + intel_detect_pch(_priv->drm);
>  
> - intel_pm_setup(dev);
> + intel_pm_setup(_priv->drm);
>   intel_init_dpio(dev_priv);
>   intel_power_domains_init(dev_priv);
>   intel_irq_init(dev_priv);
>   intel_init_display_hooks(dev_priv);
>   intel_init_clock_gating_hooks(dev_priv);
>   intel_init_audio_hooks(dev_priv);
> - i915_gem_load_init(dev);
> + i915_gem_load_init(_priv->drm);
>  
> - intel_display_crc_init(dev);
> + intel_display_crc_init(_priv->drm);
>  
>   i915_dump_device_info(dev_priv);
>  
> @@ -1132,7 +1133,7 @@ static int i915_driver_init_early(struct 
> drm_i915_private *dev_priv,
>* very first ones. Almost everything should work, except for maybe
>* suspend/resume. And we don't implement workarounds that affect only
>* pre-production machines. */
> - if (IS_HSW_EARLY_SDV(dev))
> + if (IS_HSW_EARLY_SDV(dev_priv))
>   DRM_INFO("This is an early pre-production Haswell machine. "
>"It may not be fully functional.\n");
>  
> @@ -1390,6 +1391,7 @@ static void i915_driver_register(struct 
> drm_i915_private *dev_priv)
>   struct drm_device *dev = dev_priv->dev;
>  
>   i915_gem_shrinker_init(dev_priv);
> +
>   /*
>* Notify a valid surface after modesetting,
>* when running inside a VM.
> @@ -1397,9 +1399,13 @@ static void i915_driver_register(struct 
> drm_i915_private *dev_priv)
>   if (intel_vgpu_active(dev_priv))
>   I915_WRITE(vgtif_reg(display_ready), VGT_DRV_DISPLAY_READY);
>  
> - i915_debugfs_register(dev_priv);
> - i915_setup_sysfs(dev);
> - intel_modeset_register(dev_priv);
> + /* Reveal our presence to userspace */
> + if (drm_dev_register(dev, 0) == 0) {
> + i915_debugfs_register(dev_priv);
> + 

Re: [Intel-gfx] [PATCH] drm/i915: Limit i915_ring_test_irq debugfs to actual rings

[Chris Wilson]

On Fri, Jun 17, 2016 at 02:35:05PM +0100, Chris Wilson wrote:
> For simplicity in testing, only report known rings in the mask. This
> allows userspace to try and trigger a missed irq on every ring and do a
> comparison between i915_ring_test_irq and i915_ring_missed_irq to see if
> any rings failed.
> 
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 

Ping?
-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 igt] igt: Add basic framework for GVT-g testing

[Wang, Zhi A]

Thanks. I'm learning the test framework :P Just have a few questions:
> -Original Message-
> From: Chris Wilson [mailto:chris.ickle.wil...@gmail.com] On Behalf Of Chris
> Wilson
> Sent: Tuesday, June 21, 2016 2:36 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Chris Wilson ; Wang, Zhi A
> 
> Subject: [PATCH igt] igt: Add basic framework for GVT-g testing
> 
> We don't do anything yet other than try to load the module. Initial sanity 
> checks
> to come.
> 
> Signed-off-by: Chris Wilson 
> Cc: Zhi Wang 
> ---
>  lib/Makefile.sources   |   2 +
>  lib/igt_gvt.c  | 119
> +
>  lib/igt_gvt.h  |  33 ++
>  tests/Makefile.sources |   1 +
>  tests/gvt_basic.c  |  42 +
>  5 files changed, 197 insertions(+)
>  create mode 100644 lib/igt_gvt.c
>  create mode 100644 lib/igt_gvt.h
>  create mode 100644 tests/gvt_basic.c
> 
> diff --git a/lib/Makefile.sources b/lib/Makefile.sources index 
> 7f3f8c6..3589e26
> 100644
> --- a/lib/Makefile.sources
> +++ b/lib/Makefile.sources
> @@ -14,6 +14,8 @@ libintel_tools_la_SOURCES = \
>   igt_edid_template.h \
>   igt_gt.c\
>   igt_gt.h\
> + igt_gvt.c   \
> + igt_gvt.h   \
>   igt_stats.c \
>   igt_stats.h \
>   igt_sysfs.c \
> diff --git a/lib/igt_gvt.c b/lib/igt_gvt.c new file mode 100644 index
> 000..5116ee9
> --- /dev/null
> +++ b/lib/igt_gvt.c
> @@ -0,0 +1,119 @@
> +/*
> + * Copyright © 2016 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person
> +obtaining a
> + * copy of this software and associated documentation files (the
> +"Software"),
> + * to deal in the Software without restriction, including without
> +limitation
> + * the rights to use, copy, modify, merge, publish, distribute,
> +sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom
> +the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the
> +next
> + * paragraph) shall be included in all copies or substantial portions
> +of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> +EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> +MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO
> EVENT
> +SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
> DAMAGES OR
> +OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> +ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> OTHER
> +DEALINGS
> + * IN THE SOFTWARE.
> + */
> +
> +#include "igt.h"
> +#include "igt_gvt.h"
> +
> +#include 
> +#include 
> +#include 
> +
> +static bool is_gvt_enabled(void)
> +{
> + FILE *file;
> + int value;
> + bool enabled = false;
> +
> + file = fopen("/sys/module/i915/parameters/enable_gvt", "r");
> + if (!file)
> + return false;
> +
> + if (fscanf(file, "%d", ) == 1)
> + enabled = value;
> + fclose(file);
> +
> + errno = 0;
Is there any reason to set errno to zero at this time? :P
> + return enabled;
> +}
> +
> +static void unbind_fbcon(void)
> +{
> + char buf[128];
> + const char *path = "/sys/class/vtconsole";
> + DIR *dir;
> + struct dirent *vtcon;
> +
> + dir = opendir(path);
> + if (!dir)
> + return;
> +
> + while ((vtcon = readdir(dir))) {
> + int fd, len;
> +
> + if (strncmp(vtcon->d_name, "vtcon", 5))
> + continue;
> +
> + sprintf(buf, "%s/%s/name", path, vtcon->d_name);
> + fd = open(buf, O_RDONLY);
> + if (fd < 0)
> + continue;
> +
> + len = read(fd, buf, sizeof(buf) - 1);
Will i-g-t use SIGALRM in global test framework? If yes, maybe we should check 
len == -1 && errno == -EINTR or set SA_RESTART in sigaction(SIGALRM).
> + close(fd);
> + if (len >= 0)
> + buf[len] = '\0';
> +
> + if (strstr(buf, "frame buffer device")) {
> + sprintf(buf, "%s/%s/bind", path, vtcon->d_name);
> + fd = open(buf, O_WRONLY);
> + if (fd != -1) {
> + buf[0] = '1';
> + buf[1] = '\n';
> + write(fd, buf, 2);
> + close(fd);
> + }
Better we could build a command line in buf and system(cmdline) here? :P
> + break;
> + }
> + }
> + closedir(dir);
> +}
> +
> +static void unload_i915(void)
> +{
> + 

Re: [Intel-gfx] [PATCH 5/8] drm/i915: Register debugfs interface last

[Daniel Vetter]

On Tue, Jun 21, 2016 at 09:53:45AM +0100, Chris Wilson wrote:
> Currently debugfs files are created before the driver is even loads.
> This gives the opportunity for userspace to open that interface and poke
> around before the backing data structures are initialised - with the
> possibility of oopsing or worse.
> 
> Move the creation of the debugfs files to our registration phase, where
> we announce our presence to the world when we are ready, i.e the
> sequence changes from
> 
>   drm_dev_register()
>-> drm_minor_register()
> -> drm_debugfs_init()
>  -> i915_debugfs_init()
>-> i915_driver_load()
> 
> to
> 
>   drm_dev_register()
>-> drm_minor_register()
> -> drm_debugfs_init()
>-> i915_driver_load()
> -> i915_debugfs_register()
> 
> Signed-off-by: Chris Wilson 
> Cc: Ville Syrjälä 
> Reviewed-by: Ville Syrjälä 

->debugfs_init/cleanup() is another midlayer thing we probably should nuke
over the next decade or so, like with ->load/unload() ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/8] drm/i915: Move connector registration to driver registration

[Daniel Vetter]

On Tue, Jun 21, 2016 at 09:53:44AM +0100, Chris Wilson wrote:
> +void intel_modeset_register(struct drm_i915_private *dev_priv)
> +{
> + drm_connector_register_all(dev_priv->dev);
> +}
> +
> +void intel_modeset_unregister(struct drm_i915_private *dev_priv)
> +{
> + drm_connector_unregister_all(dev_priv->dev);
> +}

Given that this will all disappear again I wouldn't bother with the
wrapper functions.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm: Refactor drop/set master code a bit

[Patchwork]

== Series Details ==

Series: drm: Refactor drop/set master code a bit
URL   : https://patchwork.freedesktop.org/series/8993/
State : failure

== Summary ==

Applying: drm: Refactor drop/set master code a bit
fatal: sha1 information is lacking or useless (include/drm/drmP.h).
error: could not build fake ancestor
Patch failed at 0001 drm: Refactor drop/set master code a bit
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

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

Re: [Intel-gfx] [PATCH] drm/i915/guc: Remove one unnecessary variable

[Daniel Vetter]

On Tue, Jun 21, 2016 at 01:48:23PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> No need for local struct drm_device * since dev_priv is the
> correct thing to pass in to NEEDS_WaRsDisableCoarsePowerGating
> anyway. Changed the macro definition for the latter to reflect
> that as well.
> 
> Signed-off-by: Tvrtko Ursulin 
> Cc: Dave Gordon 

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/i915/i915_drv.h| 7 ---
>  drivers/gpu/drm/i915/i915_guc_submission.c | 3 +--
>  2 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 48928227bdcc..3775d26ac573 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2788,9 +2788,10 @@ struct drm_i915_cmd_table {
>  #define HAS_BROKEN_CS_TLB(dev)   (IS_I830(dev) || IS_845G(dev))
>  
>  /* WaRsDisableCoarsePowerGating:skl,bxt */
> -#define NEEDS_WaRsDisableCoarsePowerGating(dev) (IS_BXT_REVID(dev, 0, 
> BXT_REVID_A1) || \
> -  IS_SKL_GT3(dev) || \
> -  IS_SKL_GT4(dev))
> +#define NEEDS_WaRsDisableCoarsePowerGating(dev_priv) (IS_BXT_REVID(dev_priv, 
> \
> +  0, BXT_REVID_A1) || \
> +  IS_SKL_GT3(dev_priv) || \
> +  IS_SKL_GT4(dev_priv))
>  
>  /*
>   * dp aux and gmbus irq on gen4 seems to be able to generate legacy 
> interrupts
> diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
> b/drivers/gpu/drm/i915/i915_guc_submission.c
> index 22a55ac4e51c..643bc3b2e3b8 100644
> --- a/drivers/gpu/drm/i915/i915_guc_submission.c
> +++ b/drivers/gpu/drm/i915/i915_guc_submission.c
> @@ -153,12 +153,11 @@ static int host2guc_sample_forcewake(struct intel_guc 
> *guc,
>struct i915_guc_client *client)
>  {
>   struct drm_i915_private *dev_priv = guc_to_i915(guc);
> - struct drm_device *dev = dev_priv->dev;
>   u32 data[2];
>  
>   data[0] = HOST2GUC_ACTION_SAMPLE_FORCEWAKE;
>   /* WaRsDisableCoarsePowerGating:skl,bxt */
> - if (!intel_enable_rc6() || NEEDS_WaRsDisableCoarsePowerGating(dev))
> + if (!intel_enable_rc6() || NEEDS_WaRsDisableCoarsePowerGating(dev_priv))
>   data[1] = 0;
>   else
>   /* bit 0 and 1 are for Render and Media domain separately */
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH] drm/i915/guc: Remove one unnecessary variable

[Chris Wilson]

On Tue, Jun 21, 2016 at 01:48:23PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> No need for local struct drm_device * since dev_priv is the
> correct thing to pass in to NEEDS_WaRsDisableCoarsePowerGating
> anyway. Changed the macro definition for the latter to reflect
> that as well.
> 
> Signed-off-by: Tvrtko Ursulin 
> Cc: Dave Gordon 
> ---
>  drivers/gpu/drm/i915/i915_drv.h| 7 ---
>  drivers/gpu/drm/i915/i915_guc_submission.c | 3 +--
>  2 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 48928227bdcc..3775d26ac573 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2788,9 +2788,10 @@ struct drm_i915_cmd_table {
>  #define HAS_BROKEN_CS_TLB(dev)   (IS_I830(dev) || IS_845G(dev))
>  
>  /* WaRsDisableCoarsePowerGating:skl,bxt */
> -#define NEEDS_WaRsDisableCoarsePowerGating(dev) (IS_BXT_REVID(dev, 0, 
> BXT_REVID_A1) || \
> -  IS_SKL_GT3(dev) || \
> -  IS_SKL_GT4(dev))
> +#define NEEDS_WaRsDisableCoarsePowerGating(dev_priv) (IS_BXT_REVID(dev_priv, 
> \
> +  0, BXT_REVID_A1) || \
> +  IS_SKL_GT3(dev_priv) || \
> +  IS_SKL_GT4(dev_priv))

#define NEEDS_WaRsDisableCoarsePowerGating(dev_priv) \
(IS_BXT_REVID(dev_priv, 0, BXT_REVID_A1) || \
 IS_SKL_GT3(dev_priv) ||
 IS_SKL_GT4(dev_priv))

Other than that,
Reviewed-by: Chris Wilson 

Just wondering if you fancy having a go at IS_SKL_GT(dev_priv, min, max)...
-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] ✗ Ro.CI.BAT: warning for drm/i915: Fix power sequencer use before init

[Imre Deak]

On ti, 2016-06-21 at 09:45 +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: Fix power sequencer use before init
> URL   : https://patchwork.freedesktop.org/series/8967/
> State : warning
> 
> == Summary ==
> 
> Series 8967v1 drm/i915: Fix power sequencer use before init
> http://patchwork.freedesktop.org/api/1.0/series/8967/revisions/1/mbox
> 
> Test kms_flip:
> Subgroup basic-flip-vs-wf_vblank:
> fail   -> PASS   (ro-snb-i7-2620M)
> Test kms_pipe_crc_basic:
> Subgroup suspend-read-crc-pipe-a:
> skip   -> DMESG-WARN (ro-bdw-i5-5250u)
> Subgroup suspend-read-crc-pipe-b:
> skip   -> DMESG-WARN (ro-bdw-i5-5250u)
> Subgroup suspend-read-crc-pipe-c:
> skip   -> DMESG-WARN (ro-bdw-i5-5250u)

All the above are pre-existing issues and not related to these patches
since the machine above doesn't have an eDP connection. I opened a bug:
https://bugs.freedesktop.org/show_bug.cgi?id=96614

After suspend-to-ram and resume on an external DP output:

[  291.867864] [drm:intel_enable_shared_dpll] enable LCPLL 1350 (active 1, on? 
0) for crtc 26
[  291.867865] [drm:intel_enable_shared_dpll] enabling LCPLL 1350
[  291.870603] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7145000c
...
[  291.950407] [drm:drm_dp_dpcd_access] too many retries, giving up
...
[  292.119813] [drm:intel_dp_sink_dpms] failed to enable sink power state
...
[  292.373085] [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* 
failed to enable link training
...
[  292.458254] [drm:intel_dp_start_link_train [i915]] *ERROR* failed to start 
channel equalization

> 
> fi-skl-i5-
> 6260u  total:225  pass:200  dwarn:0   dfail:0   fail:2   skip:23 
> fi-skl-i7-
> 6700k  total:225  pass:186  dwarn:0   dfail:0   fail:2   skip:37 
> fi-snb-i7-
> 2600   total:225  pass:172  dwarn:0   dfail:0   fail:2   skip:51 
> ro-bdw-i5-
> 5250u  total:225  pass:197  dwarn:4   dfail:0   fail:0   skip:24 
> ro-bdw-i7-
> 5600u  total:225  pass:185  dwarn:0   dfail:0   fail:0   skip:40 
> ro-byt-
> n2820 total:225  pass:173  dwarn:0   dfail:0   fail:3   skip:49 
> ro-hsw-i3-
> 4010u  total:225  pass:190  dwarn:0   dfail:0   fail:0   skip:35 
> ro-hsw-i7-
> 4770r  total:225  pass:190  dwarn:0   dfail:0   fail:0   skip:35 
> ro-ilk-i7-
> 620lm  total:225  pass:150  dwarn:0   dfail:0   fail:1   skip:74 
> ro-ilk1-i5-
> 650   total:220  pass:150  dwarn:0   dfail:0   fail:1   skip:69 
> ro-ivb-i7-
> 3770   total:225  pass:181  dwarn:0   dfail:0   fail:0   skip:44 
> ro-ivb2-i7-
> 3770  total:225  pass:185  dwarn:0   dfail:0   fail:0   skip:40 
> ro-skl3-i5-6260u
> total:225  pass:201  dwarn:1   dfail:0   fail:0   skip:23 
> ro-snb-i7-
> 2620M  total:225  pass:174  dwarn:0   dfail:0   fail:1   skip:50 
> fi-hsw-i7-4770k failed to connect after reboot
> ro-bdw-i7-5557U failed to connect after reboot
> 
> Results at /archive/results/CI_IGT_test/RO_Patchwork_1249/
> 
> 79c69c3 drm-intel-nightly: 2016y-06m-21d-08h-53m-58s UTC integration
> manifest
> 8464015 drm/i915: Group all the PPS init steps to one place
> d07dffd drm/i915: Initialize the PPS HW before its first use
> 1ce6454 drm/i915/ibx, cpt: Don't attempt to register eDP if LVDS was
> detected
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v10 2/6] drm/i915: Convert requests to use struct fence

[Maarten Lankhorst]

Op 16-06-16 om 14:54 schreef john.c.harri...@intel.com:
> From: John Harrison 
>
> There is a construct in the linux kernel called 'struct fence' that is
> intended to keep track of work that is executed on hardware. I.e. it
> solves the basic problem that the drivers 'struct
> drm_i915_gem_request' is trying to address. The request structure does
> quite a lot more than simply track the execution progress so is very
> definitely still required. However, the basic completion status side
> could be updated to use the ready made fence implementation and gain
> all the advantages that provides.
>
> This patch makes the first step of integrating a struct fence into the
> request. It replaces the explicit reference count with that of the
> fence. It also replaces the 'is completed' test with the fence's
> equivalent. Currently, that simply chains on to the original request
> implementation. A future patch will improve this.
>
> v3: Updated after review comments by Tvrtko Ursulin. Added fence
> context/seqno pair to the debugfs request info. Renamed fence 'driver
> name' to just 'i915'. Removed BUG_ONs.
>
> v5: Changed seqno format in debugfs to %x rather than %u as that is
> apparently the preferred appearance. Line wrapped some long lines to
> keep the style checker happy.
>
> v6: Updated to newer nigthly and resolved conflicts. The biggest issue
> was with the re-worked busy spin precursor to waiting on a request. In
> particular, the addition of a 'request_started' helper function. This
> has no corresponding concept within the fence framework. However, it
> is only ever used in one place and the whole point of that place is to
> always directly read the seqno for absolutely lowest latency possible.
> So the simple solution is to just make the seqno test explicit at that
> point now rather than later in the series (it was previously being
> done anyway when fences become interrupt driven).
>
> v7: Rebased to newer nightly - lots of ring -> engine renaming and
> interface change to get_seqno().
>
> v8: Rebased to newer nightly - no longer needs to worry about mutex
> locking in the request free code path. Moved to after fence timeline
> patch so no longer needs to add a horrid hack timeline.
>
> Removed commented out code block. Added support for possible RCU usage
> of fence object (Review comments by Maarten Lankhorst).
>
> v10: Removed duplicate rcu_head field from request - there is already
> one in the fence structure for this exact purpose. Improved/added some
> comments. [Review comments from Maarten Lankhorst & Tvrtko Ursulin]
>
> Updated for yet more nightly changes (u64 for fence context).
Reviewed-by: Maarten Lankhorst 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Ro.CI.BAT: success for drm: Lobotomize set_busid nonsense for !pci drivers

[Patchwork]

== Series Details ==

Series: drm: Lobotomize set_busid nonsense for !pci drivers
URL   : https://patchwork.freedesktop.org/series/8989/
State : success

== Summary ==

Series 8989v1 drm: Lobotomize set_busid nonsense for !pci drivers
http://patchwork.freedesktop.org/api/1.0/series/8989/revisions/1/mbox

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> SKIP   (ro-bdw-i5-5250u)

fi-hsw-i7-4770k  total:225  pass:192  dwarn:0   dfail:0   fail:2   skip:31 
fi-skl-i5-6260u  total:225  pass:200  dwarn:0   dfail:0   fail:2   skip:23 
fi-skl-i7-6700k  total:225  pass:186  dwarn:0   dfail:0   fail:2   skip:37 
fi-snb-i7-2600   total:225  pass:172  dwarn:0   dfail:0   fail:2   skip:51 
ro-bdw-i5-5250u  total:225  pass:197  dwarn:1   dfail:0   fail:0   skip:27 
ro-bdw-i7-5600u  total:225  pass:185  dwarn:0   dfail:0   fail:0   skip:40 
ro-byt-n2820 total:225  pass:173  dwarn:0   dfail:0   fail:3   skip:49 
ro-hsw-i3-4010u  total:225  pass:190  dwarn:0   dfail:0   fail:0   skip:35 
ro-hsw-i7-4770r  total:225  pass:190  dwarn:0   dfail:0   fail:0   skip:35 
ro-ilk-i7-620lm  total:225  pass:150  dwarn:0   dfail:0   fail:1   skip:74 
ro-ilk1-i5-650   total:220  pass:150  dwarn:0   dfail:0   fail:1   skip:69 
ro-ivb-i7-3770   total:225  pass:181  dwarn:0   dfail:0   fail:0   skip:44 
ro-ivb2-i7-3770  total:225  pass:185  dwarn:0   dfail:0   fail:0   skip:40 
ro-skl3-i5-6260u total:225  pass:201  dwarn:1   dfail:0   fail:0   skip:23 
ro-snb-i7-2620M  total:225  pass:174  dwarn:0   dfail:0   fail:1   skip:50 
fi-bxt-q6he failed to connect after reboot
fi-kbl-qkkr failed to connect after reboot
ro-bdw-i7-5557U failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1254/

2cdff39 drm-intel-nightly: 2016y-06m-21d-11h-54m-56s UTC integration manifest
0f182b1 drm: Lobotomize set_busid nonsense for !pci drivers

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

[Intel-gfx] [PATCH] drm/i915/guc: Remove one unnecessary variable

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

No need for local struct drm_device * since dev_priv is the
correct thing to pass in to NEEDS_WaRsDisableCoarsePowerGating
anyway. Changed the macro definition for the latter to reflect
that as well.

Signed-off-by: Tvrtko Ursulin 
Cc: Dave Gordon 
---
 drivers/gpu/drm/i915/i915_drv.h| 7 ---
 drivers/gpu/drm/i915/i915_guc_submission.c | 3 +--
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 48928227bdcc..3775d26ac573 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2788,9 +2788,10 @@ struct drm_i915_cmd_table {
 #define HAS_BROKEN_CS_TLB(dev) (IS_I830(dev) || IS_845G(dev))
 
 /* WaRsDisableCoarsePowerGating:skl,bxt */
-#define NEEDS_WaRsDisableCoarsePowerGating(dev) (IS_BXT_REVID(dev, 0, 
BXT_REVID_A1) || \
-IS_SKL_GT3(dev) || \
-IS_SKL_GT4(dev))
+#define NEEDS_WaRsDisableCoarsePowerGating(dev_priv) (IS_BXT_REVID(dev_priv, \
+0, BXT_REVID_A1) || \
+IS_SKL_GT3(dev_priv) || \
+IS_SKL_GT4(dev_priv))
 
 /*
  * dp aux and gmbus irq on gen4 seems to be able to generate legacy interrupts
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 22a55ac4e51c..643bc3b2e3b8 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -153,12 +153,11 @@ static int host2guc_sample_forcewake(struct intel_guc 
*guc,
 struct i915_guc_client *client)
 {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
-   struct drm_device *dev = dev_priv->dev;
u32 data[2];
 
data[0] = HOST2GUC_ACTION_SAMPLE_FORCEWAKE;
/* WaRsDisableCoarsePowerGating:skl,bxt */
-   if (!intel_enable_rc6() || NEEDS_WaRsDisableCoarsePowerGating(dev))
+   if (!intel_enable_rc6() || NEEDS_WaRsDisableCoarsePowerGating(dev_priv))
data[1] = 0;
else
/* bit 0 and 1 are for Render and Media domain separately */
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH v10 1/6] drm/i915: Add per context timelines for fence objects

[Maarten Lankhorst]

Op 16-06-16 om 14:54 schreef john.c.harri...@intel.com:
> From: John Harrison 
>
> The purpose of this patch series is to convert the requst structure to
> use fence objects for the underlying completion tracking. The fence
> object requires a sequence number. The ultimate aim is to use the same
> sequence number as for the request itself (or rather, to remove the
> request's seqno field and just use the fence's value throughout the
> driver). However, this is not currently possible and so this patch
> introduces a separate numbering scheme as an intermediate step.
>
> A major advantage of using the fence object is that it can be passed
> outside of the i915 driver and used externally. The fence API allows
> for various operations such as combining multiple fences. This
> requires that fence seqnos within a single fence context be guaranteed
> in-order. The GPU scheduler that is coming can re-order request
> execution but not within a single GPU context. Thus the fence context
> must be tied to the i915 context (and the engine within the context as
> each engine runs asynchronously).
>
> On the other hand, the driver as a whole currently only works with
> request seqnos that are allocated from a global in-order timeline. It
> will require a fair chunk of re-work to allow multiple independent
> seqno timelines to be used. Hence the introduction of a temporary,
> fence specific timeline. Once the work to update the rest of the
> driver has been completed then the request can use the fence seqno
> instead.
>
> v2: New patch in series.
>
> v3: Renamed/retyped timeline structure fields after review comments by
> Tvrtko Ursulin.
>
> Added context information to the timeline's name string for better
> identification in debugfs output.
>
> v5: Line wrapping and other white space fixes to keep style checker
> happy.
>
> v7: Updated to newer nightly (lots of ring -> engine renaming).
>
> v8: Moved to earlier in patch series so no longer needs to remove the
> quick hack timeline that was being added before.
>
> v9: Updated to another newer nightly (changes to context structure
> naming). Also updated commit message to match previous changes.
>
> v10: Removed obsolete fields from timeline structure and a couple of
> functions. Corrected some comments and debug prints. [Review comments
> from Maarten Lankhorst & Tvrtko Ursulin]
>
> Updated to yet more nightly changes (u64 for fence context).
>
> For: VIZ-5190
> Signed-off-by: John Harrison 
> Cc: Tvrtko Ursulin 
> Cc: Maarten Lankhorst 

Reviewed-by: Maarten Lankhorst 

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

Re: [Intel-gfx] [RFC i-g-t v3 08/13] lib/stubs: Add stubs for intel_bufmgr.

[Marius Vlad]

On Mon, Jun 20, 2016 at 03:52:35PM +0100, Emil Velikov wrote:
> Hi Rob,
> 
> A couple of nitpicks and a case of missing git add :-)
> 
> On 15 June 2016 at 10:51,   wrote:
> 
> > +if HAVE_LIBDRM_INTEL
> > +else
> > +libintel_tools_la_SOURCES +=   \
> > +stubs/drm/intel_bufmgr.c   \
> > +stubs/drm/intel_bufmgr.h
> > +endif
> > +
> I believe I mentioned if before - please use the following construct
> 
> if !HAVE_LIBDRM_INTEL
> libintel_tools_la_SOURCES +=   \
> stubs/drm/intel_bufmgr.c   \
> stubs/drm/intel_bufmgr.h
> endif
> 
> >  AM_CPPFLAGS = -I$(top_srcdir)
> >  AM_CFLAGS = $(CWARNFLAGS) $(DRM_CFLAGS) $(PCIACCESS_CFLAGS) 
> > $(LIBUNWIND_CFLAGS) $(DEBUG_CFLAGS) \
> > -DIGT_SRCDIR=\""$(abs_top_srcdir)/tests"\" \
> > diff --git a/lib/stubs/drm/README b/lib/stubs/drm/README
> > new file mode 100644
> > index 000..dec6a1d
> > --- /dev/null
> > +++ b/lib/stubs/drm/README
> > @@ -0,0 +1,4 @@
> > +intel_bufmgr.h is a copy the file provided in libdrm 
> > (intel/intel_bufmgr.h).
> > +
> s/copy the file provided in/local copy of the file provided by/
> 
> Sadly that's not the case atm. There's a fair few changes in the local 'copy'.
> Perhaps you forgot to git add ?
> 
> > +Before releasing i-g-t a current copy of intel_bufmgr.h should be copied 
> > into
> > +this directory of i-g-t.

Auch, but synchronizing this wouldn't be a nightmare? I mean stubs
might be added/removed in the future.

> 
> Thinking about it... I'm not sure that the release manager will find
> this note here :-\
> 
> Daniel V, Marius, do you guys have a tick-off list somewhere where
> this could be added ?

README and NEWS. Don't know of any other.

> 
> Regards,
> Emil


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

Re: [Intel-gfx] [PATCH i-g-t v2] tests/drm_lib.sh: Extract fake getopt options so it can sourced into tests that require it.

[Chris Wilson]

On Tue, Jun 21, 2016 at 03:34:07PM +0300, Marius Vlad wrote:
> This should allow tests/vgem_reload_basic to pass check target and it
> doesn't depend of i915 being present.
> 
> v2: Do not source drm_lib.sh, only fake getopt parsing
> option to again access to --list-subtests option (Chris)
> 
> Signed-off-by: Marius Vlad 
> CC: Chris Wilson 
Reviewed-by: Chris Wilson 

Might want to change the exit 1 to exit $IGT_FAILURE now.
-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: Drop mode_config.mutex from get_resources ioctl

[Daniel Vetter]

The only thing this protected is the connector_list, which is
now protected differently.

v2: Also remove comment (Chris).

Cc: Chris Wilson 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_crtc.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 13c3bacc6b51..f8931b82865a 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1904,9 +1904,6 @@ int drm_mode_getresources(struct drm_device *dev, void 
*data,
card_res->count_fbs = fb_count;
mutex_unlock(_priv->fbs_lock);
 
-   /* mode_config.mutex protects the connector list against e.g. DP MST
-* connector hot-adding. CRTC/Plane lists are invariant. */
-   mutex_lock(>mode_config.mutex);
card_res->max_height = dev->mode_config.max_height;
card_res->min_height = dev->mode_config.min_height;
card_res->max_width = dev->mode_config.max_width;
@@ -1961,7 +1958,6 @@ int drm_mode_getresources(struct drm_device *dev, void 
*data,
card_res->count_connectors = connector_count;
 
 out:
-   mutex_unlock(>mode_config.mutex);
return ret;
 }
 
-- 
2.8.1

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

Re: [Intel-gfx] [PATCH] drm: Don't compute obj counts expensively in get_resources

[Chris Wilson]

On Tue, Jun 21, 2016 at 02:29:48PM +0200, Daniel Vetter wrote:
> Looping when we keep track of this is silly. Only thing we have to
> be careful is with sampling the connector count. To avoid inconsisten
> results due to gcc re-computing this, use READ_ONCE.
> 
> And to avoid surprising userspace, make sure we don't copy more
> connectors than planned, and report the actual number of connectors
> copied. That way any racing hot-add/remove will be handled.
> 
> v2: Actually try to not blow up, somehow I lost the hunk that checks
> we don't copy too much. Noticed by Chris.
> 
> Cc: Chris Wilson 
> Signed-off-by: Daniel Vetter 

The defacto API is call once with count_connectors=0 then with again
with the previous value of count_connectors. On the second pass, the
user is expecting no more then count_connectors to be copied, and is not
expecting to be told about new ones. The expected ABI looks unchanged.

> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 28c109ff7330..59c5261a309c 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -1842,10 +1842,10 @@ int drm_mode_getresources(struct drm_device *dev, 
> void *data,
>   struct drm_crtc *crtc;
>   struct drm_encoder *encoder;
>   int ret = 0;
> - int connector_count = 0;
> - int crtc_count = 0;
> + int connector_count = READ_ONCE(dev->mode_config.num_connector);

Ok, since in the future num_connector is not guarded by mode_conf.mutex,
moving the read underneath that lock doesn't obviate the need for
READ_ONCE. Still it reduces the window and how far one has too look back
if it were set just before the connector loop.

Reviewed-by: Chris Wilson 
-Chris

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

[Intel-gfx] [PATCH i-g-t v2] tests/drm_lib.sh: Extract fake getopt options so it can sourced into tests that require it.

[Marius Vlad]

This should allow tests/vgem_reload_basic to pass check target and it
doesn't depend of i915 being present.

v2: Do not source drm_lib.sh, only fake getopt parsing
option to again access to --list-subtests option (Chris)

Signed-off-by: Marius Vlad 
CC: Chris Wilson 
---
 tests/drm_getopt.sh | 38 ++
 tests/drm_lib.sh| 35 ++-
 tests/vgem_reload_basic |  3 +++
 3 files changed, 43 insertions(+), 33 deletions(-)
 create mode 100644 tests/drm_getopt.sh

diff --git a/tests/drm_getopt.sh b/tests/drm_getopt.sh
new file mode 100644
index 000..a94a759
--- /dev/null
+++ b/tests/drm_getopt.sh
@@ -0,0 +1,38 @@
+# This is required for check/distcheck target as it has to --list-subtests
+# for each test. Source it if you add a new test in form of a (shell) script.
+
+# See tests/vgem_reload_basic
+
+IGT_EXIT_TIMEOUT=78
+IGT_EXIT_SKIP=77
+IGT_EXIT_SUCCESS=0
+IGT_EXIT_INVALID=79
+IGT_EXIT_FAILURE=99
+
+# hacked-up long option parsing
+for arg in $@ ; do
+   case $arg in
+   --list-subtests)
+   exit $IGT_EXIT_INVALID
+   ;;
+   --run-subtest)
+   exit $IGT_EXIT_INVALID
+   ;;
+   --debug)
+   IGT_LOG_LEVEL=debug
+   ;;
+   --help-description)
+   echo $IGT_TEST_DESCRIPTION
+   exit $IGT_EXIT_SUCCESS
+   ;;
+   --help)
+   echo "Usage: `basename $0` [OPTIONS]"
+   echo "  --list-subtests"
+   echo "  --run-subtest "
+   echo "  --debug"
+   echo "  --help-description"
+   echo "  --help"
+   exit $IGT_EXIT_SUCCESS
+   ;;
+   esac
+done
diff --git a/tests/drm_lib.sh b/tests/drm_lib.sh
index 2ba146b..c32bc68 100755
--- a/tests/drm_lib.sh
+++ b/tests/drm_lib.sh
@@ -1,38 +1,7 @@
 #!/bin/sh
 
-IGT_EXIT_TIMEOUT=78
-IGT_EXIT_SKIP=77
-IGT_EXIT_SUCCESS=0
-IGT_EXIT_INVALID=79
-IGT_EXIT_FAILURE=99
-
-# hacked-up long option parsing
-for arg in $@ ; do
-   case $arg in
-   --list-subtests)
-   exit $IGT_EXIT_INVALID
-   ;;
-   --run-subtest)
-   exit $IGT_EXIT_INVALID
-   ;;
-   --debug)
-   IGT_LOG_LEVEL=debug
-   ;;
-   --help-description)
-   echo $IGT_TEST_DESCRIPTION
-   exit $IGT_EXIT_SUCCESS
-   ;;
-   --help)
-   echo "Usage: `basename $0` [OPTIONS]"
-   echo "  --list-subtests"
-   echo "  --run-subtest "
-   echo "  --debug"
-   echo "  --help-description"
-   echo "  --help"
-   exit $IGT_EXIT_SUCCESS
-   ;;
-   esac
-done
+SOURCE_DIR="$( dirname "${BASH_SOURCE[0]}" )"
+. $SOURCE_DIR/drm_getopt.sh
 
 skip() {
echo "$@"
diff --git a/tests/vgem_reload_basic b/tests/vgem_reload_basic
index b150b2c..a42da70 100755
--- a/tests/vgem_reload_basic
+++ b/tests/vgem_reload_basic
@@ -5,6 +5,9 @@
 # ... we've broken this way too often :(
 #
 
+SOURCE_DIR="$( dirname "${BASH_SOURCE[0]}" )"
+. $SOURCE_DIR/drm_getopt.sh
+
 function unload() {
/sbin/rmmod vgem
# drm may be used by other devices (nouveau, radeon, udl, etc)
-- 
2.8.1

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

[Intel-gfx] [PATCH] drm: Don't compute obj counts expensively in get_resources

[Daniel Vetter]

Looping when we keep track of this is silly. Only thing we have to
be careful is with sampling the connector count. To avoid inconsisten
results due to gcc re-computing this, use READ_ONCE.

And to avoid surprising userspace, make sure we don't copy more
connectors than planned, and report the actual number of connectors
copied. That way any racing hot-add/remove will be handled.

v2: Actually try to not blow up, somehow I lost the hunk that checks
we don't copy too much. Noticed by Chris.

Cc: Chris Wilson 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_crtc.c | 19 +++
 1 file changed, 7 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 28c109ff7330..59c5261a309c 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1842,10 +1842,10 @@ int drm_mode_getresources(struct drm_device *dev, void 
*data,
struct drm_crtc *crtc;
struct drm_encoder *encoder;
int ret = 0;
-   int connector_count = 0;
-   int crtc_count = 0;
+   int connector_count = READ_ONCE(dev->mode_config.num_connector);
+   int crtc_count = dev->mode_config.num_crtc;
int fb_count = 0;
-   int encoder_count = 0;
+   int encoder_count = dev->mode_config.num_encoder;
int copied = 0;
uint32_t __user *fb_id;
uint32_t __user *crtc_id;
@@ -1883,15 +1883,6 @@ int drm_mode_getresources(struct drm_device *dev, void 
*data,
/* mode_config.mutex protects the connector list against e.g. DP MST
 * connector hot-adding. CRTC/Plane lists are invariant. */
mutex_lock(>mode_config.mutex);
-   drm_for_each_crtc(crtc, dev)
-   crtc_count++;
-
-   drm_for_each_connector(connector, dev)
-   connector_count++;
-
-   drm_for_each_encoder(encoder, dev)
-   encoder_count++;
-
card_res->max_height = dev->mode_config.max_height;
card_res->min_height = dev->mode_config.min_height;
card_res->max_width = dev->mode_config.max_width;
@@ -1931,6 +1922,9 @@ int drm_mode_getresources(struct drm_device *dev, void 
*data,
copied = 0;
connector_id = (uint32_t __user *)(unsigned 
long)card_res->connector_id_ptr;
drm_for_each_connector(connector, dev) {
+   if (copied >= connector_count)
+   break;
+
if (put_user(connector->base.id,
 connector_id + copied)) {
ret = -EFAULT;
@@ -1938,6 +1932,7 @@ int drm_mode_getresources(struct drm_device *dev, void 
*data,
}
copied++;
}
+   connector_count = copied;
}
card_res->count_connectors = connector_count;
 
-- 
2.8.1

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

Re: [Intel-gfx] [PATCH v10 6/6] drm/i915: Cache last IRQ seqno to reduce IRQ overhead

[Maarten Lankhorst]

Op 16-06-16 om 14:54 schreef john.c.harri...@intel.com:
> From: John Harrison 
>
> The notify function can be called many times without the seqno
> changing. Some are to prevent races due to the requirement of not
> enabling interrupts until requested. However, when interrupts are
> enabled the IRQ handler can be called multiple times without the
> ring's seqno value changing. E.g. two interrupts are generated by
> batch buffers completing in quick succession, the first call to the
> handler processes both completions but the handler still gets executed
> a second time. This patch reduces the overhead of these extra calls by
> caching the last processed seqno value and early exiting if it has not
> changed.
>
> v3: New patch for series.
>
> v5: Added comment about last_irq_seqno usage due to code review
> feedback (Tvrtko Ursulin).
>
> v6: Minor update to resolve a race condition with the wait_request
> optimisation.
>
> v7: Updated to newer nightly - lots of ring -> engine renaming plus an
> interface change to get_seqno().
>
> v10: Renamed the cached variable as it is no longer used at IRQ time.
> [Review comment from Tvrtko Ursulin]
>
> For: VIZ-5190
> Signed-off-by: John Harrison 
> Cc: Maarten Lankhorst 
> Cc: Tvrtko Ursulin 

I think it would be useful to add in the commit message that this happens in 
most cases.

From your earlier mail:

"Doing the cache check hits the early exit approx 98% of the time when 
running GLBenchmark. Although the vast majority of duplicate calls are 
from having to call the notify function from 
i915_gem_retire_requests_ring() and that being called at least once for 
every execbuf IOCTL (possibly multiple times). I have just made a couple 
of tweaks to further reduce the number of these calls and their impact, 
but there are still a lot of them."

If added,

Reviewed-by: Maarten Lankhorst 

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

[Intel-gfx] ✗ Ro.CI.BAT: failure for Documentation: convert DocBook gpu.tmpl to reStructuredText (rev2)

[Patchwork]

== Series Details ==

Series: Documentation: convert DocBook gpu.tmpl to reStructuredText (rev2)
URL   : https://patchwork.freedesktop.org/series/8931/
State : failure

== Summary ==

Applying: Documentation/gpu: add new gpu.rst converted from DocBook gpu.tmpl
Using index info to reconstruct a base tree...
M   Documentation/index.rst
Falling back to patching base and 3-way merge...
Auto-merging Documentation/index.rst
CONFLICT (content): Merge conflict in Documentation/index.rst
error: Failed to merge in the changes.
Patch failed at 0001 Documentation/gpu: add new gpu.rst converted from DocBook 
gpu.tmpl
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

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

Re: [Intel-gfx] [PATCH igt] igt: Add basic framework for GVT-g testing

[Wang, Zhi A]

Ha, I see. Additional signal handler to call the exit handlers. :P

> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Tuesday, June 21, 2016 3:22 PM
> To: Wang, Zhi A 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [PATCH igt] igt: Add basic framework for GVT-g testing
> 
> On Tue, Jun 21, 2016 at 12:17:48PM +, Wang, Zhi A wrote:
> > To me, atexit is not reliable. As if something wrong happened during the 
> > test
> and an unexpected signal was received, the prog would be aborted. atexit()
> would not work on that case. Better do failsafe work in parent process and run
> the test case in child process I think.
> 
> Welcome to igt. atexit here handles signals, but we don't yet have universal
> setup/cleanup. Just a wishlist.
> -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 igt] igt: Add basic framework for GVT-g testing

[Chris Wilson]

On Tue, Jun 21, 2016 at 12:17:48PM +, Wang, Zhi A wrote:
> To me, atexit is not reliable. As if something wrong happened during the test 
> and an unexpected signal was received, the prog would be aborted. atexit() 
> would not work on that case. Better do failsafe work in parent process and 
> run the test case in child process I think.

Welcome to igt. atexit here handles signals, but we don't yet have
universal setup/cleanup. Just a wishlist.
-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 02/10] drm: Don't compute obj counts expensively in get_resources

[Daniel Vetter]

On Tue, Jun 21, 2016 at 10:48:08AM +0100, Chris Wilson wrote:
> On Tue, Jun 21, 2016 at 11:10:27AM +0200, Daniel Vetter wrote:
> > And to avoid surprising userspace, make sure we don't copy more
> > connectors than planned, and report the actual number of connectors
> > copied. That way any racing hot-add/remove will be handled.
> 
> > @@ -1938,6 +1929,7 @@ int drm_mode_getresources(struct drm_device *dev, 
> > void *data,
> > }
> > copied++;
> > }
> > +   connector_count = copied;
> 
> You forgot to actually make sure we don't copy more conectors than
> planned.

Indeed, must have lost that hunk somewhere. At least I'm sure I've typed
it ;-) Will resend.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm: Refactor drop/set master code a bit

[Daniel Vetter]

File open/set_maseter ioctl and file close/drop_master ioctl share the
same master handling code. Extract it.

Note that vmwgfx's master_set callback needs to know whether the
master is a new one or has been used already, so thread this through.
On the close/drop side a similar parameter existed, but wasnt used.
Drop it to simplify the flow.

v2: Try to make it not leak so much (Emil).

v3: Send out the right version ...

Cc: Emil Velikov 
Cc: Chris Wilson 
Cc: Thomas Hellstrom 
Reviewed-by: Chris Wilson 
Reviewed-by: Emil Velikov 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_auth.c  | 80 +++--
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |  3 +-
 include/drm/drmP.h  |  3 +-
 3 files changed, 44 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index 6bba6b9e9dcc..2794a4f3a105 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -110,6 +110,24 @@ static struct drm_master *drm_master_create(struct 
drm_device *dev)
return master;
 }
 
+static int drm_set_master(struct drm_device *dev, struct drm_file *fpriv,
+ bool new_master)
+{
+   int ret = 0;
+
+   dev->master = drm_master_get(fpriv->master);
+   fpriv->is_master = 1;
+   if (dev->driver->master_set) {
+   ret = dev->driver->master_set(dev, fpriv, new_master);
+   if (unlikely(ret != 0)) {
+   fpriv->is_master = 0;
+   drm_master_put(>master);
+   }
+   }
+
+   return ret;
+}
+
 /*
  * drm_new_set_master - Allocate a new master object and become master for the
  * associated master realm.
@@ -127,37 +145,32 @@ static int drm_new_set_master(struct drm_device *dev, 
struct drm_file *fpriv)
 
lockdep_assert_held_once(>master_mutex);
 
-   /* create a new master */
-   dev->master = drm_master_create(dev);
-   if (!dev->master)
-   return -ENOMEM;
-
-   /* take another reference for the copy in the local file priv */
old_master = fpriv->master;
-   fpriv->master = drm_master_get(dev->master);
+   fpriv->master = drm_master_create(dev);
+   if (!fpriv->master) {
+   fpriv->master = old_master;
+   return -ENOMEM;
+   }
 
if (dev->driver->master_create) {
ret = dev->driver->master_create(dev, fpriv->master);
if (ret)
goto out_err;
}
-   if (dev->driver->master_set) {
-   ret = dev->driver->master_set(dev, fpriv, true);
-   if (ret)
-   goto out_err;
-   }
-
-   fpriv->is_master = 1;
fpriv->allowed_master = 1;
fpriv->authenticated = 1;
+
+   ret = drm_set_master(dev, fpriv, true);
+   if (ret)
+   goto out_err;
+
if (old_master)
drm_master_put(_master);
 
return 0;
 
 out_err:
-   /* drop both references and restore old master on failure */
-   drm_master_put(>master);
+   /* drop references and restore old master on failure */
drm_master_put(>master);
fpriv->master = old_master;
 
@@ -188,21 +201,21 @@ int drm_setmaster_ioctl(struct drm_device *dev, void 
*data,
goto out_unlock;
}
 
-   dev->master = drm_master_get(file_priv->master);
-   file_priv->is_master = 1;
-   if (dev->driver->master_set) {
-   ret = dev->driver->master_set(dev, file_priv, false);
-   if (unlikely(ret != 0)) {
-   file_priv->is_master = 0;
-   drm_master_put(>master);
-   }
-   }
-
+   ret = drm_set_master(dev, file_priv, false);
 out_unlock:
mutex_unlock(>master_mutex);
return ret;
 }
 
+static void drm_drop_master(struct drm_device *dev,
+   struct drm_file *fpriv)
+{
+   if (dev->driver->master_drop)
+   dev->driver->master_drop(dev, fpriv);
+   drm_master_put(>master);
+   fpriv->is_master = 0;
+}
+
 int drm_dropmaster_ioctl(struct drm_device *dev, void *data,
 struct drm_file *file_priv)
 {
@@ -216,11 +229,7 @@ int drm_dropmaster_ioctl(struct drm_device *dev, void 
*data,
goto out_unlock;
 
ret = 0;
-   if (dev->driver->master_drop)
-   dev->driver->master_drop(dev, file_priv, false);
-   drm_master_put(>master);
-   file_priv->is_master = 0;
-
+   drm_drop_master(dev, file_priv);
 out_unlock:
mutex_unlock(>master_mutex);
return ret;
@@ -271,17 +280,12 @@ void drm_master_release(struct drm_file *file_priv)
mutex_unlock(>struct_mutex);
}
 
-   if (dev->master == 

Re: [Intel-gfx] [PATCH igt] igt: Add basic framework for GVT-g testing

[Wang, Zhi A]

> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Tuesday, June 21, 2016 3:08 PM
> To: Wang, Zhi A 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [PATCH igt] igt: Add basic framework for GVT-g testing
> 
> On Tue, Jun 21, 2016 at 12:01:02PM +, Wang, Zhi A wrote:
> >
> >
> > > -Original Message-
> > > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> > > Sent: Tuesday, June 21, 2016 2:55 PM
> > > To: intel-gfx@lists.freedesktop.org
> > > Cc: Wang, Zhi A 
> > > Subject: Re: [PATCH igt] igt: Add basic framework for GVT-g testing
> > >
> > > On Tue, Jun 21, 2016 at 12:36:06PM +0100, Chris Wilson wrote:
> > > > +static bool is_gvt_enabled(void)
> > > > +{
> > > > +   FILE *file;
> > > > +   int value;
> > > > +   bool enabled = false;
> > > > +
> > > > +   file = fopen("/sys/module/i915/parameters/enable_gvt", "r");
> > > > +   if (!file)
> > > > +   return false;
> > > > +
> > > > +   if (fscanf(file, "%d", ) == 1)
> > > > +   enabled = value;
> > > > +   fclose(file);
> > > > +
> > > > +   errno = 0;
> > > > +   return enabled;
> > > > +}
> > > > +
> > > > +static void unbind_fbcon(void)
> > > > +{
> > > > +   char buf[128];
> > > > +   const char *path = "/sys/class/vtconsole";
> > > > +   DIR *dir;
> > > > +   struct dirent *vtcon;
> > > > +
> > > > +   dir = opendir(path);
> > > > +   if (!dir)
> > > > +   return;
> > > > +
> > > > +   while ((vtcon = readdir(dir))) {
> > > > +   int fd, len;
> > > > +
> > > > +   if (strncmp(vtcon->d_name, "vtcon", 5))
> > > > +   continue;
> > > > +
> > > > +   sprintf(buf, "%s/%s/name", path, vtcon->d_name);
> > > > +   fd = open(buf, O_RDONLY);
> > > > +   if (fd < 0)
> > > > +   continue;
> > > > +
> > > > +   len = read(fd, buf, sizeof(buf) - 1);
> > > > +   close(fd);
> > > > +   if (len >= 0)
> > > > +   buf[len] = '\0';
> > > > +
> > > > +   if (strstr(buf, "frame buffer device")) {
> > > > +   sprintf(buf, "%s/%s/bind", path, vtcon->d_name);
> > > > +   fd = open(buf, O_WRONLY);
> > > > +   if (fd != -1) {
> > > > +   buf[0] = '1';
> > > > +   buf[1] = '\n';
> > > > +   write(fd, buf, 2);
> > > > +   close(fd);
> > > > +   }
> > > > +   break;
> > > > +   }
> > > > +   }
> > > > +   closedir(dir);
> > > > +}
> > > > +
> > > > +static void unload_i915(void)
> > > > +{
> > > > +   unbind_fbcon();
> > > > +   /* pkill alsact */
> > > > +
> > > > +   system("/sbin/modprobe -s -r i915"); }
> > > > +
> > > > +bool igt_gvt_load_module(void)
> > > > +{
> > > > +   if (is_gvt_enabled())
> > > > +   return true;
> > > > +
> > > > +   unload_i915();
> > > > +   system("/sbin/modprobe -s i915 enable_gvt=1");
> > > > +
> > > > +   return is_gvt_enabled();
> > >
> > > Would it be safe to put igt_gvt_unload_module() into an exit handler?
> > >
> > Would you mind to elaborate your concern here? I assume you want to
> > register igt_gvt_unload_module() via atexit(). :D
> 
> Yes. I was thinking that it would be more convenient to tests to automatically
> cleanup and restore the previous state. However, an error path is likely to 
> leave
> the module in-use during our atexit handler and so prevent us from unloading
> the module. Still it is one thing less to remember when writing a test case.
> 
> The problem with the atexit handler is that it needs to be sigsafe. The use of
> fopen here could be problematic for instance.


I didn't find this one from my "man 3 atexit". Where do you find this? :D
> -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 v2 0/7] Documentation: convert DocBook gpu.tmpl to reStructuredText

[Daniel Vetter]

On Tue, Jun 21, 2016 at 02:48:56PM +0300, Jani Nikula wrote:
> Take two of [1], see the cover letter there.
> 
> I've renamed drm-userland-interfaces.rst to drm-uapi.rst and added a
> further split-up patch of drm internals, extracting mm, kms and kms
> helpers to separate documents.

All applied to drm-misc. Thanks a lot for all your work on improving the
doc toolchain!

Cheers, Daniel

> 
> BR,
> Jani.
> 
> [1] http://mid.gmane.org/cover.1466434348.git.jani.nik...@intel.com
> 
> 
> Jani Nikula (7):
>   Documentation/gpu: add new gpu.rst converted from DocBook gpu.tmpl
>   Documentation/gpu: split up the gpu documentation
>   MAINTAINERS: add Documentation/gpu and Documentation/gpu/i915.rst
>   Documentation/gpu: use recommended order of heading markers
>   Documentation/gpu: convert the KMS properties table to CSV
>   Documentation/gpu: split up mm, kms and kms-helpers from internals
>   Documentation/DocBook: remove gpu.tmpl
> 
>  Documentation/DocBook/Makefile|2 +-
>  Documentation/DocBook/gpu.tmpl| 3528 
> -
>  Documentation/gpu/drm-internals.rst   |  378 
>  Documentation/gpu/drm-kms-helpers.rst |  260 +++
>  Documentation/gpu/drm-kms.rst |  656 ++
>  Documentation/gpu/drm-mm.rst  |  454 +
>  Documentation/gpu/drm-uapi.rst|   92 +
>  Documentation/gpu/i915.rst|  347 
>  Documentation/gpu/index.rst   |   14 +
>  Documentation/gpu/introduction.rst|   51 +
>  Documentation/gpu/kms-properties.csv  |  128 ++
>  Documentation/gpu/vga-switcheroo.rst  |  102 +
>  Documentation/index.rst   |1 +
>  MAINTAINERS   |3 +-
>  14 files changed, 2486 insertions(+), 3530 deletions(-)
>  delete mode 100644 Documentation/DocBook/gpu.tmpl
>  create mode 100644 Documentation/gpu/drm-internals.rst
>  create mode 100644 Documentation/gpu/drm-kms-helpers.rst
>  create mode 100644 Documentation/gpu/drm-kms.rst
>  create mode 100644 Documentation/gpu/drm-mm.rst
>  create mode 100644 Documentation/gpu/drm-uapi.rst
>  create mode 100644 Documentation/gpu/i915.rst
>  create mode 100644 Documentation/gpu/index.rst
>  create mode 100644 Documentation/gpu/introduction.rst
>  create mode 100644 Documentation/gpu/kms-properties.csv
>  create mode 100644 Documentation/gpu/vga-switcheroo.rst
> 
> -- 
> 2.1.4
> 

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

Re: [Intel-gfx] [PATCH igt] igt: Add basic framework for GVT-g testing

[Wang, Zhi A]

> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Tuesday, June 21, 2016 3:08 PM
> To: Wang, Zhi A 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [PATCH igt] igt: Add basic framework for GVT-g testing
> 
> On Tue, Jun 21, 2016 at 12:01:02PM +, Wang, Zhi A wrote:
> >
> >
> > > -Original Message-
> > > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> > > Sent: Tuesday, June 21, 2016 2:55 PM
> > > To: intel-gfx@lists.freedesktop.org
> > > Cc: Wang, Zhi A 
> > > Subject: Re: [PATCH igt] igt: Add basic framework for GVT-g testing
> > >
> > > On Tue, Jun 21, 2016 at 12:36:06PM +0100, Chris Wilson wrote:
> > > > +static bool is_gvt_enabled(void)
> > > > +{
> > > > +   FILE *file;
> > > > +   int value;
> > > > +   bool enabled = false;
> > > > +
> > > > +   file = fopen("/sys/module/i915/parameters/enable_gvt", "r");
> > > > +   if (!file)
> > > > +   return false;
> > > > +
> > > > +   if (fscanf(file, "%d", ) == 1)
> > > > +   enabled = value;
> > > > +   fclose(file);
> > > > +
> > > > +   errno = 0;
> > > > +   return enabled;
> > > > +}
> > > > +
> > > > +static void unbind_fbcon(void)
> > > > +{
> > > > +   char buf[128];
> > > > +   const char *path = "/sys/class/vtconsole";
> > > > +   DIR *dir;
> > > > +   struct dirent *vtcon;
> > > > +
> > > > +   dir = opendir(path);
> > > > +   if (!dir)
> > > > +   return;
> > > > +
> > > > +   while ((vtcon = readdir(dir))) {
> > > > +   int fd, len;
> > > > +
> > > > +   if (strncmp(vtcon->d_name, "vtcon", 5))
> > > > +   continue;
> > > > +
> > > > +   sprintf(buf, "%s/%s/name", path, vtcon->d_name);
> > > > +   fd = open(buf, O_RDONLY);
> > > > +   if (fd < 0)
> > > > +   continue;
> > > > +
> > > > +   len = read(fd, buf, sizeof(buf) - 1);
> > > > +   close(fd);
> > > > +   if (len >= 0)
> > > > +   buf[len] = '\0';
> > > > +
> > > > +   if (strstr(buf, "frame buffer device")) {
> > > > +   sprintf(buf, "%s/%s/bind", path, vtcon->d_name);
> > > > +   fd = open(buf, O_WRONLY);
> > > > +   if (fd != -1) {
> > > > +   buf[0] = '1';
> > > > +   buf[1] = '\n';
> > > > +   write(fd, buf, 2);
> > > > +   close(fd);
> > > > +   }
> > > > +   break;
> > > > +   }
> > > > +   }
> > > > +   closedir(dir);
> > > > +}
> > > > +
> > > > +static void unload_i915(void)
> > > > +{
> > > > +   unbind_fbcon();
> > > > +   /* pkill alsact */
> > > > +
> > > > +   system("/sbin/modprobe -s -r i915"); }
> > > > +
> > > > +bool igt_gvt_load_module(void)
> > > > +{
> > > > +   if (is_gvt_enabled())
> > > > +   return true;
> > > > +
> > > > +   unload_i915();
> > > > +   system("/sbin/modprobe -s i915 enable_gvt=1");
> > > > +
> > > > +   return is_gvt_enabled();
> > >
> > > Would it be safe to put igt_gvt_unload_module() into an exit handler?
> > >
> > Would you mind to elaborate your concern here? I assume you want to
> > register igt_gvt_unload_module() via atexit(). :D
> 
> Yes. I was thinking that it would be more convenient to tests to automatically
> cleanup and restore the previous state. However, an error path is likely to 
> leave
> the module in-use during our atexit handler and so prevent us from unloading
> the module. Still it is one thing less to remember when writing a test case.
> 
> The problem with the atexit handler is that it needs to be sigsafe. The use of
> fopen here could be problematic for instance.


To me, atexit is not reliable. As if something wrong happened during the test 
and an unexpected signal was received, the prog would be aborted. atexit() 
would not work on that case. Better do failsafe work in parent process and run 
the test case in child process I think.

> -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: Lobotomize set_busid nonsense for !pci drivers

[Daniel Vetter]

We already have a fallback in place to fill out the unique from
dev->unique, which is set to something reasonable in drm_dev_alloc.

Which means we only need to have a special set_busid for pci devices,
to be able to care the backwards compat code for drm 1.1 around, which
libdrm still needs.

While developing and testing this patch things blew up in really
interesting ways, and the code is rather confusing in naming things
between the kernel code, ioctl #defines and libdrm. For the next brave
dragon slayer, document all this madness properly in the userspace
interface section of gpu.tmpl.

v2: Make drm_dev_set_unique static and update kerneldoc.

v3: Entire rewrite, plus document what's going on for posterity in the
gpu docbook uapi section.

v4: Drop accidental amdgpu hunk (Emil).

v5: Drop accidental omapdrm vblank counter change (Emil).

Cc: Gustavo Padovan 
Cc: Emil Velikov 
Tested-by: Gustavo Padovan  (virt_gpu)
Reviewed-by: Emil Velikov 
Signed-off-by: Daniel Vetter 
---
 Documentation/DocBook/gpu.tmpl  |  4 ++
 drivers/gpu/drm/armada/armada_drv.c |  1 -
 drivers/gpu/drm/drm_ioctl.c | 58 +
 drivers/gpu/drm/drm_platform.c  | 18 
 drivers/gpu/drm/etnaviv/etnaviv_drv.c   |  1 -
 drivers/gpu/drm/exynos/exynos_drm_drv.c |  1 -
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c |  1 -
 drivers/gpu/drm/imx/imx-drm-core.c  |  1 -
 drivers/gpu/drm/msm/msm_drv.c   |  1 -
 drivers/gpu/drm/nouveau/nouveau_drm.c   |  1 -
 drivers/gpu/drm/omapdrm/omap_drv.c  |  1 -
 drivers/gpu/drm/shmobile/shmob_drm_drv.c|  1 -
 drivers/gpu/drm/tilcdc/tilcdc_drv.c |  1 -
 drivers/gpu/drm/virtio/virtgpu_drm_bus.c| 10 -
 drivers/gpu/drm/virtio/virtgpu_drv.c|  1 -
 drivers/gpu/drm/virtio/virtgpu_drv.h|  1 -
 include/drm/drmP.h  |  1 -
 17 files changed, 62 insertions(+), 41 deletions(-)

diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
index a836a8bcd289..94c6bdee8080 100644
--- a/Documentation/DocBook/gpu.tmpl
+++ b/Documentation/DocBook/gpu.tmpl
@@ -3099,6 +3099,10 @@ int num_ioctls;
   
 
 
+  libdrm Device Lookup
+!Pdrivers/gpu/drm/drm_vma_manager.c getunique and setversion story
+
+
   Render nodes
   
 DRM core provides multiple character-devices for user-space to use.
diff --git a/drivers/gpu/drm/armada/armada_drv.c 
b/drivers/gpu/drm/armada/armada_drv.c
index cb21c0b6374a..f5ebdd681445 100644
--- a/drivers/gpu/drm/armada/armada_drv.c
+++ b/drivers/gpu/drm/armada/armada_drv.c
@@ -189,7 +189,6 @@ static struct drm_driver armada_drm_driver = {
.load   = armada_drm_load,
.lastclose  = armada_drm_lastclose,
.unload = armada_drm_unload,
-   .set_busid  = drm_platform_set_busid,
.get_vblank_counter = drm_vblank_no_hw_counter,
.enable_vblank  = armada_drm_enable_vblank,
.disable_vblank = armada_drm_disable_vblank,
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 1fa7619face3..063775f7946e 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -37,6 +37,64 @@
 #include 
 #include 
 
+/**
+ * DOC: getunique and setversion story
+ *
+ * BEWARE THE DRAGONS! MIND THE TRAPDOORS!
+ *
+ * In and attempt to warn anyone else who's trying to figure out what's going
+ * on here, I'll try to summarize the story. First things first, let's clear up
+ * the names, because the kernel internals, libdrm and the ioctls are all named
+ * differently:
+ *
+ *  - GET_UNIQUE ioctl, implemented by drm_getunique is wrapped up in libdrm
+ *through the drmGetBusid function.
+ *  - The libdrm drmSetBusid function is backed by the SET_UNIQUE ioctl. All
+ *that code is nerved in the kernel with drm_invalid_op().
+ *  - The internal set_busid kernel functions and driver callbacks are
+ *exclusively use by the SET_VERSION ioctl, because only drm 1.0 (which is
+ *nerved) allowed userspace to set the busid through the above ioctl.
+ *  - Other ioctls and functions involved are named consistently.
+ *
+ * For anyone wondering what's the difference between drm 1.1 and 1.4: 
Correctly
+ * handling pci domains in the busid on ppc. Doing this correctly was only
+ * implemented in libdrm in 2010, hence can't be nerved yet. No one knows 
what's
+ * special with drm 1.2 and 1.3.
+ *
+ * Now the actual horror story of how device lookup in drm works. At large,
+ * there's 2 different ways, either by busid, or by device driver name.
+ *
+ * Opening by busid is fairly simple:
+ *
+ * 1. First call SET_VERSION to make sure pci domains are handled 

Re: [Intel-gfx] [PATCH igt] igt: Add basic framework for GVT-g testing

[Chris Wilson]

On Tue, Jun 21, 2016 at 12:01:02PM +, Wang, Zhi A wrote:
> 
> 
> > -Original Message-
> > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> > Sent: Tuesday, June 21, 2016 2:55 PM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Wang, Zhi A 
> > Subject: Re: [PATCH igt] igt: Add basic framework for GVT-g testing
> > 
> > On Tue, Jun 21, 2016 at 12:36:06PM +0100, Chris Wilson wrote:
> > > +static bool is_gvt_enabled(void)
> > > +{
> > > + FILE *file;
> > > + int value;
> > > + bool enabled = false;
> > > +
> > > + file = fopen("/sys/module/i915/parameters/enable_gvt", "r");
> > > + if (!file)
> > > + return false;
> > > +
> > > + if (fscanf(file, "%d", ) == 1)
> > > + enabled = value;
> > > + fclose(file);
> > > +
> > > + errno = 0;
> > > + return enabled;
> > > +}
> > > +
> > > +static void unbind_fbcon(void)
> > > +{
> > > + char buf[128];
> > > + const char *path = "/sys/class/vtconsole";
> > > + DIR *dir;
> > > + struct dirent *vtcon;
> > > +
> > > + dir = opendir(path);
> > > + if (!dir)
> > > + return;
> > > +
> > > + while ((vtcon = readdir(dir))) {
> > > + int fd, len;
> > > +
> > > + if (strncmp(vtcon->d_name, "vtcon", 5))
> > > + continue;
> > > +
> > > + sprintf(buf, "%s/%s/name", path, vtcon->d_name);
> > > + fd = open(buf, O_RDONLY);
> > > + if (fd < 0)
> > > + continue;
> > > +
> > > + len = read(fd, buf, sizeof(buf) - 1);
> > > + close(fd);
> > > + if (len >= 0)
> > > + buf[len] = '\0';
> > > +
> > > + if (strstr(buf, "frame buffer device")) {
> > > + sprintf(buf, "%s/%s/bind", path, vtcon->d_name);
> > > + fd = open(buf, O_WRONLY);
> > > + if (fd != -1) {
> > > + buf[0] = '1';
> > > + buf[1] = '\n';
> > > + write(fd, buf, 2);
> > > + close(fd);
> > > + }
> > > + break;
> > > + }
> > > + }
> > > + closedir(dir);
> > > +}
> > > +
> > > +static void unload_i915(void)
> > > +{
> > > + unbind_fbcon();
> > > + /* pkill alsact */
> > > +
> > > + system("/sbin/modprobe -s -r i915"); }
> > > +
> > > +bool igt_gvt_load_module(void)
> > > +{
> > > + if (is_gvt_enabled())
> > > + return true;
> > > +
> > > + unload_i915();
> > > + system("/sbin/modprobe -s i915 enable_gvt=1");
> > > +
> > > + return is_gvt_enabled();
> > 
> > Would it be safe to put igt_gvt_unload_module() into an exit handler?
> > 
> Would you mind to elaborate your concern here? I assume you want to register 
> igt_gvt_unload_module() via atexit(). :D

Yes. I was thinking that it would be more convenient to tests to
automatically cleanup and restore the previous state. However, an error
path is likely to leave the module in-use during our atexit handler and
so prevent us from unloading the module. Still it is one thing less to
remember when writing a test case.

The problem with the atexit handler is that it needs to be sigsafe. The
use of fopen here could be problematic for instance.
-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 igt] igt: Add basic framework for GVT-g testing

[Wang, Zhi A]

> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Tuesday, June 21, 2016 2:55 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Wang, Zhi A 
> Subject: Re: [PATCH igt] igt: Add basic framework for GVT-g testing
> 
> On Tue, Jun 21, 2016 at 12:36:06PM +0100, Chris Wilson wrote:
> > +static bool is_gvt_enabled(void)
> > +{
> > +   FILE *file;
> > +   int value;
> > +   bool enabled = false;
> > +
> > +   file = fopen("/sys/module/i915/parameters/enable_gvt", "r");
> > +   if (!file)
> > +   return false;
> > +
> > +   if (fscanf(file, "%d", ) == 1)
> > +   enabled = value;
> > +   fclose(file);
> > +
> > +   errno = 0;
> > +   return enabled;
> > +}
> > +
> > +static void unbind_fbcon(void)
> > +{
> > +   char buf[128];
> > +   const char *path = "/sys/class/vtconsole";
> > +   DIR *dir;
> > +   struct dirent *vtcon;
> > +
> > +   dir = opendir(path);
> > +   if (!dir)
> > +   return;
> > +
> > +   while ((vtcon = readdir(dir))) {
> > +   int fd, len;
> > +
> > +   if (strncmp(vtcon->d_name, "vtcon", 5))
> > +   continue;
> > +
> > +   sprintf(buf, "%s/%s/name", path, vtcon->d_name);
> > +   fd = open(buf, O_RDONLY);
> > +   if (fd < 0)
> > +   continue;
> > +
> > +   len = read(fd, buf, sizeof(buf) - 1);
> > +   close(fd);
> > +   if (len >= 0)
> > +   buf[len] = '\0';
> > +
> > +   if (strstr(buf, "frame buffer device")) {
> > +   sprintf(buf, "%s/%s/bind", path, vtcon->d_name);
> > +   fd = open(buf, O_WRONLY);
> > +   if (fd != -1) {
> > +   buf[0] = '1';
> > +   buf[1] = '\n';
> > +   write(fd, buf, 2);
> > +   close(fd);
> > +   }
> > +   break;
> > +   }
> > +   }
> > +   closedir(dir);
> > +}
> > +
> > +static void unload_i915(void)
> > +{
> > +   unbind_fbcon();
> > +   /* pkill alsact */
> > +
> > +   system("/sbin/modprobe -s -r i915"); }
> > +
> > +bool igt_gvt_load_module(void)
> > +{
> > +   if (is_gvt_enabled())
> > +   return true;
> > +
> > +   unload_i915();
> > +   system("/sbin/modprobe -s i915 enable_gvt=1");
> > +
> > +   return is_gvt_enabled();
> 
> Would it be safe to put igt_gvt_unload_module() into an exit handler?
> 
Would you mind to elaborate your concern here? I assume you want to register 
igt_gvt_unload_module() via atexit(). :D
> > +}
> > +
> > +void igt_gvt_unload_module(void)
> > +{
> > +   if (!is_gvt_enabled())
> > +   return;
> > +
> > +   unload_i915();
> > +   system("/sbin/modprobe -s i915 enable_gvt=0");
> > +
> > +   igt_assert(!is_gvt_enabled());
> > +}
> 
> --
> 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 igt] igt: Add basic framework for GVT-g testing

[Chris Wilson]

On Tue, Jun 21, 2016 at 12:36:06PM +0100, Chris Wilson wrote:
> +static bool is_gvt_enabled(void)
> +{
> + FILE *file;
> + int value;
> + bool enabled = false;
> +
> + file = fopen("/sys/module/i915/parameters/enable_gvt", "r");
> + if (!file)
> + return false;
> +
> + if (fscanf(file, "%d", ) == 1)
> + enabled = value;
> + fclose(file);
> +
> + errno = 0;
> + return enabled;
> +}
> +
> +static void unbind_fbcon(void)
> +{
> + char buf[128];
> + const char *path = "/sys/class/vtconsole";
> + DIR *dir;
> + struct dirent *vtcon;
> +
> + dir = opendir(path);
> + if (!dir)
> + return;
> +
> + while ((vtcon = readdir(dir))) {
> + int fd, len;
> +
> + if (strncmp(vtcon->d_name, "vtcon", 5))
> + continue;
> +
> + sprintf(buf, "%s/%s/name", path, vtcon->d_name);
> + fd = open(buf, O_RDONLY);
> + if (fd < 0)
> + continue;
> +
> + len = read(fd, buf, sizeof(buf) - 1);
> + close(fd);
> + if (len >= 0)
> + buf[len] = '\0';
> +
> + if (strstr(buf, "frame buffer device")) {
> + sprintf(buf, "%s/%s/bind", path, vtcon->d_name);
> + fd = open(buf, O_WRONLY);
> + if (fd != -1) {
> + buf[0] = '1';
> + buf[1] = '\n';
> + write(fd, buf, 2);
> + close(fd);
> + }
> + break;
> + }
> + }
> + closedir(dir);
> +}
> +
> +static void unload_i915(void)
> +{
> + unbind_fbcon();
> + /* pkill alsact */
> +
> + system("/sbin/modprobe -s -r i915");
> +}
> +
> +bool igt_gvt_load_module(void)
> +{
> + if (is_gvt_enabled())
> + return true;
> +
> + unload_i915();
> + system("/sbin/modprobe -s i915 enable_gvt=1");
> +
> + return is_gvt_enabled();

Would it be safe to put igt_gvt_unload_module() into an exit handler?

> +}
> +
> +void igt_gvt_unload_module(void)
> +{
> + if (!is_gvt_enabled())
> + return;
> +
> + unload_i915();
> + system("/sbin/modprobe -s i915 enable_gvt=0");
> +
> + igt_assert(!is_gvt_enabled());
> +}

-- 
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 v2 0/7] Documentation: convert DocBook gpu.tmpl to reStructuredText

[Jani Nikula]

Take two of [1], see the cover letter there.

I've renamed drm-userland-interfaces.rst to drm-uapi.rst and added a
further split-up patch of drm internals, extracting mm, kms and kms
helpers to separate documents.

BR,
Jani.

[1] http://mid.gmane.org/cover.1466434348.git.jani.nik...@intel.com


Jani Nikula (7):
  Documentation/gpu: add new gpu.rst converted from DocBook gpu.tmpl
  Documentation/gpu: split up the gpu documentation
  MAINTAINERS: add Documentation/gpu and Documentation/gpu/i915.rst
  Documentation/gpu: use recommended order of heading markers
  Documentation/gpu: convert the KMS properties table to CSV
  Documentation/gpu: split up mm, kms and kms-helpers from internals
  Documentation/DocBook: remove gpu.tmpl

 Documentation/DocBook/Makefile|2 +-
 Documentation/DocBook/gpu.tmpl| 3528 -
 Documentation/gpu/drm-internals.rst   |  378 
 Documentation/gpu/drm-kms-helpers.rst |  260 +++
 Documentation/gpu/drm-kms.rst |  656 ++
 Documentation/gpu/drm-mm.rst  |  454 +
 Documentation/gpu/drm-uapi.rst|   92 +
 Documentation/gpu/i915.rst|  347 
 Documentation/gpu/index.rst   |   14 +
 Documentation/gpu/introduction.rst|   51 +
 Documentation/gpu/kms-properties.csv  |  128 ++
 Documentation/gpu/vga-switcheroo.rst  |  102 +
 Documentation/index.rst   |1 +
 MAINTAINERS   |3 +-
 14 files changed, 2486 insertions(+), 3530 deletions(-)
 delete mode 100644 Documentation/DocBook/gpu.tmpl
 create mode 100644 Documentation/gpu/drm-internals.rst
 create mode 100644 Documentation/gpu/drm-kms-helpers.rst
 create mode 100644 Documentation/gpu/drm-kms.rst
 create mode 100644 Documentation/gpu/drm-mm.rst
 create mode 100644 Documentation/gpu/drm-uapi.rst
 create mode 100644 Documentation/gpu/i915.rst
 create mode 100644 Documentation/gpu/index.rst
 create mode 100644 Documentation/gpu/introduction.rst
 create mode 100644 Documentation/gpu/kms-properties.csv
 create mode 100644 Documentation/gpu/vga-switcheroo.rst

-- 
2.1.4

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

[Intel-gfx] [PATCH v2 4/7] Documentation/gpu: use recommended order of heading markers

[Jani Nikula]

While splitting the document up, the headings "shifted" from what pandoc
generated. Use the following order for headings for consistency:

==
Document title
==

First
=

Second
--

Third
~

Leave the lower level headings as they are; I think those are less
important. Although RST doesn't mandate a specific order ("Rather than
imposing a fixed number and order of section title adornment styles, the
order enforced will be the order as encountered."), having the higher
levels the same overall makes it easier to follow the documents.

[I'm sort of kind of writing the recommendation for docs-next in the
mean time, but this order seems sensible, and is what I'm proposing.]

Signed-off-by: Jani Nikula 
---
 Documentation/gpu/drm-internals.rst | 127 ++--
 Documentation/gpu/drm-uapi.rst  |   5 +-
 Documentation/gpu/i915.rst  |  81 +++
 Documentation/gpu/introduction.rst  |   3 +-
 4 files changed, 110 insertions(+), 106 deletions(-)

diff --git a/Documentation/gpu/drm-internals.rst 
b/Documentation/gpu/drm-internals.rst
index 8b8257891396..ee01a4fbd657 100644
--- a/Documentation/gpu/drm-internals.rst
+++ b/Documentation/gpu/drm-internals.rst
@@ -1,3 +1,4 @@
+=
 DRM Internals
 =
 
@@ -18,7 +19,7 @@ management, command submission & fencing, suspend/resume 
support, and
 DMA services.
 
 Driver Initialization
--
+=
 
 At the core of every DRM driver is a :c:type:`struct drm_driver
 ` structure. Drivers typically statically initialize
@@ -36,7 +37,7 @@ then describe individual operations in details as they get 
used in later
 sections.
 
 Driver Information
-~~
+--
 
 Driver Features
 ^^^
@@ -131,7 +132,7 @@ kernel log at initialization time and passes it to 
userspace through the
 DRM_IOCTL_VERSION ioctl.
 
 Device Instance and Driver Handling
-~~~
+---
 
 .. kernel-doc:: drivers/gpu/drm/drm_drv.c
:doc: driver instance overview
@@ -140,7 +141,7 @@ Device Instance and Driver Handling
:export:
 
 Driver Load
-~~~
+---
 
 IRQ Registration
 
@@ -221,7 +222,7 @@ other BARs, so leaving it mapped could cause undesired 
behaviour like
 hangs or memory corruption.
 
 Bus-specific Device Registration and PCI Support
-
+
 
 A number of functions are provided to help with device registration. The
 functions deal with PCI and platform devices respectively and are only
@@ -236,7 +237,7 @@ drivers.
:export:
 
 Memory management
--
+=
 
 Modern Linux systems require large amount of graphics memory to store
 frame buffers, textures, vertices and other graphics-related data. Given
@@ -262,7 +263,7 @@ TTM, but has no video RAM management capabilities and is 
thus limited to
 UMA devices.
 
 The Translation Table Manager (TTM)
-~~~
+---
 
 TTM design background and information belongs here.
 
@@ -313,7 +314,7 @@ object, ttm_global_item_ref() is used to create an initial 
reference
 count for the TTM, which will call your initialization function.
 
 The Graphics Execution Manager (GEM)
-
+
 
 The GEM design approach has resulted in a memory manager that doesn't
 provide full coverage of all (or even all common) use cases in its
@@ -576,7 +577,7 @@ available to the client. Such resource management should be 
abstracted
 from the client in libdrm.
 
 GEM Function Reference
-~~
+--
 
 .. kernel-doc:: drivers/gpu/drm/drm_gem.c
:export:
@@ -585,7 +586,7 @@ GEM Function Reference
:internal:
 
 VMA Offset Manager
-~~
+--
 
 .. kernel-doc:: drivers/gpu/drm/drm_vma_manager.c
:doc: vma offset manager
@@ -597,7 +598,7 @@ VMA Offset Manager
:internal:
 
 PRIME Buffer Sharing
-
+
 
 PRIME is the cross device buffer sharing framework in drm, originally
 created for the OPTIMUS range of multi-gpu platforms. To userspace PRIME
@@ -648,13 +649,13 @@ PRIME Helper Functions
:doc: PRIME Helpers
 
 PRIME Function References
-~
+-
 
 .. kernel-doc:: drivers/gpu/drm/drm_prime.c
:export:
 
 DRM MM Range Allocator
-~~
+--
 
 Overview
 
@@ -669,7 +670,7 @@ LRU Scan/Eviction Support
:doc: lru scan roaster
 
 DRM MM Range Allocator Function References
-~~
+--
 
 .. kernel-doc:: drivers/gpu/drm/drm_mm.c
:export:
@@ -678,7 +679,7 @@ DRM MM Range Allocator 

[Intel-gfx] [PATCH v2 3/7] MAINTAINERS: add Documentation/gpu and Documentation/gpu/i915.rst

[Jani Nikula]

We'll want to keep an eye on what's going on in these files.

Signed-off-by: Jani Nikula 
---
 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index cb88f724e07c..ce9c23dd02c6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3857,6 +3857,7 @@ F:drivers/gpu/vga/
 F: Documentation/devicetree/bindings/display/
 F: Documentation/devicetree/bindings/gpu/
 F: Documentation/devicetree/bindings/video/
+F: Documentation/gpu/
 F: Documentation/DocBook/gpu.*
 F: include/drm/
 F: include/uapi/drm/
@@ -3909,6 +3910,7 @@ S:Supported
 F: drivers/gpu/drm/i915/
 F: include/drm/i915*
 F: include/uapi/drm/i915_drm.h
+F: Documentation/gpu/i915.rst
 
 DRM DRIVERS FOR ATMEL HLCDC
 M: Boris Brezillon 
-- 
2.1.4

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

Re: [Intel-gfx] [PATCH] drm/i915/gvt: Mark i915.enable_gvt as false if loading fails

[Wang, Zhi A]

> -Original Message-
> From: Chris Wilson [mailto:chris.ickle.wil...@gmail.com] On Behalf Of Chris
> Wilson
> Sent: Tuesday, June 21, 2016 2:07 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Chris Wilson ; Wang, Zhi A
> 
> Subject: [PATCH] drm/i915/gvt: Mark i915.enable_gvt as false if loading fails
> 
> If we update the value of i195.enable_gvt if we fail to load GVT userspace can
should be i915. :D

> easily detect if when it fails to load as requested.
> 
> Signed-off-by: Chris Wilson 
> Cc: Zhi Wang 
> ---
>  drivers/gpu/drm/i915/intel_gvt.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_gvt.c 
> b/drivers/gpu/drm/i915/intel_gvt.c
> index 9fa458c..434f4d5 100644
> --- a/drivers/gpu/drm/i915/intel_gvt.c
> +++ b/drivers/gpu/drm/i915/intel_gvt.c
> @@ -63,7 +63,7 @@ int intel_gvt_init(struct drm_i915_private *dev_priv)
> 
>   if (!is_supported_device(dev_priv)) {
>   DRM_DEBUG_DRIVER("Unsupported device. GVT-g is disabled\n");
> - return 0;
> + goto bail;
>   }
> 
>   /*
> @@ -72,16 +72,20 @@ int intel_gvt_init(struct drm_i915_private *dev_priv)
>   ret = intel_gvt_init_host();
>   if (ret) {
>   DRM_DEBUG_DRIVER("Not in host or MPT modules not found\n");
> - return 0;
> + goto bail;
>   }
> 
>   ret = intel_gvt_init_device(dev_priv);
>   if (ret) {
>   DRM_DEBUG_DRIVER("Fail to init GVT device\n");
> - return 0;
> + goto bail;
>   }
> 
>   return 0;
> +
> +bail:
> + i915.enable_gvt = 0;
> + return 0;
>  }
> 
>  /**
> --
> 2.8.1

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