Re: [Intel-gfx] [REGRESSION] i915: No HDMI output with 4.4

[Jindal, Sonika]

On 2/23/2016 8:38 PM, Ville Syrjälä wrote:

On Mon, Feb 22, 2016 at 02:32:32PM +0200, Oleksandr Natalenko wrote:

Ville, Daniel,

any additional info I could provide? I have to return dual-link DVI
cable back, so let me know if I could reveal more details if necessary.

Unfortunately I'm out of ideas for now. Daniel is on vacation.
Anyone else? VPG folks should take the ball here since they broke it.

In the meantime I think as a workaround I think you could use
something like video=HDMI-A-1:e on the kernel command line (not sure
I got the connector name right for your system). I think that should
result in the live status check to be skipped, at least when
populating the mode list.

Might be a good idea to collect all the information here and put in a
bug report (https://bugs.freedesktop.org/ -> DRI -> DRM/Intel) so that
all the logs and such would be in one place.


Regards,
Oleksandr

16.02.2016 14:54, Daniel Vetter написав:

On Tue, Feb 16, 2016 at 12:58:56PM +0200, Oleksandr Natalenko wrote:

Ville, Daniel,

I've just got another monitor and another DVI-HDMI cable, and here
what I've
got.

===Single Link DVI-D cable with 3 different monitors===

Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI LG 23MP65HQ-P
===
not working

I presume the above LG screen is what you've called previously "old
monitor"?


Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI LG 23MP67HQ-P
===
not working
Do you have logs for the failure with the single link hdmi cable and the 
register dump which you have given for the working case?

If not, can you please capture the logs and register dump.
Also which platform is this?
If it is live status related issue, we need to see how long it is taking 
to set the live status, or is it not setting it at all with the 
single-link cable?




Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI LG 23MP55HQ-P
===
works!

===Dual Link DVI-D cable with monitor that doesn't work with Single
Link
cable===

Computer DVI ——— DVI-D (Dual Link)/HDMI cable ——— HDMI LG 23MP65HQ-P
===
works!

Funky. Can you pls grab the debug logs (with the special patches from
Ville) for this case? I wonder why suddenly different cable and it
works.

Also: Is this one of these older-ish screens where you must have a
dual-link cable to drive it at full resolution rate?
-Daniel



===Laptop with HDMI output===

Laptop HDMI ——— HDMI/HDMI cable ——— HDMI LG 23MP65HQ-P === works!

I'd say that single link DVI cables are broken with new kernel, but
one of
monitors could work with such a cable. So I have no idea :(.

Regards,
   Oleksandr.

15.02.2016 17:42, Daniel Vetter wrote:

The other downside is that it'll make us non-compliant, which was the
point of this entire ordeal: HDMI spec forbids us from starting any i2c
transactions when the hpd isn't signalling a present screen.

So maybe we need to buy one of these broken screens.

Oleksandr, what exact model are you using? And any chance that you could
test this on some other machine with intel gfx and latest kernel, just to
make sure this really is some issue with the sink and not with the machine
itself? And I guess you've tested with some other hdmi sink, and that
works?


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

Re: [Intel-gfx] [PATCH] drm/i915: Resume DP MST before doing any kind of modesetting

[Thulasimani, Sivakumar]

On 2/24/2016 3:41 AM, Lyude wrote:

As it turns out, resuming DP MST is racey since we don't make sure MST
is ready before we start modesetting, it just usually happens to be
ready in time. This isn't the case on all systems, particularly a
ThinkPad T560 with displays connected through the dock. On these
systems, resuming the laptop while connected to the dock usually results
in blank monitors. Making sure MST is ready before doing any kind of
modesetting fixes this issue.

basic question since i haven't worked on MST much. MST should work like any
other digital panel on resume. i.e detect followed by modeset. in the 
modified
commit mentioned below is it failing to detect the panel or failing at 
the modeset ?

if we are depending on the intel_display_resume, how about moving the
intel_dp_mst_resume just above intel_display_resume?


Generic question to others in mail list on i915_drm_resume
we are doing a modeset and then doing the detect/hpd init.
shouldn't this be the other way round ? almost all displays
will pass a modeset even if display is not connected so we
are spending time on modeset even for displays that were
removed during the suspend state. if this is to simply
drm_state being saved and restored,

We originally changed the resume order in

commit e7d6f7d70829 ("drm/i915: resume MST after reading back hw state")

to fix a ton of WARN_ON's after resume, but this doesn't seem to be an
issue now anyhow.

CC: sta...@vger.kernel.org
Signed-off-by: Lyude 
---
  drivers/gpu/drm/i915/i915_drv.c | 10 --
  1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index f357058..4dcf3dd 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -733,6 +733,14 @@ static int i915_drm_resume(struct drm_device *dev)
intel_opregion_setup(dev);
  
  	intel_init_pch_refclk(dev);

+
+   /*
+* We need to make sure that we resume MST before doing anything
+* display related, otherwise we risk trying to bring up a display on
+* MST before the hub is actually ready
+*/
+   intel_dp_mst_resume(dev);
+

This does not look proper. if the CD clock is turned off during suspend
our dpcd read itself might fail till we enable CD Clock.

regards,
Sivakumar

drm_mode_config_reset(dev);
  
  	/*

@@ -765,8 +773,6 @@ static int i915_drm_resume(struct drm_device *dev)
intel_display_resume(dev);
drm_modeset_unlock_all(dev);
  
-	intel_dp_mst_resume(dev);

-
/*
 * ... but also need to make sure that hotplug processing
 * doesn't cause havoc. Like in the driver load code we don't


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

Re: [Intel-gfx] [PATCH] drm/i915: Add two-stage ILK-style watermark programming (v11)

[Matt Roper]

On Tue, Feb 23, 2016 at 05:20:13PM -0800, Matt Roper wrote:
> In addition to calculating final watermarks, let's also pre-calculate a
> set of intermediate watermark values at atomic check time.  These
> intermediate watermarks are a combination of the watermarks for the old
> state and the new state; they should satisfy the requirements of both
> states which means they can be programmed immediately when we commit the
> atomic state (without waiting for a vblank).  Once the vblank does
> happen, we can then re-program watermarks to the more optimal final
> value.
> 
> v2: Significant rebasing/rewriting.
> 
> v3:
>  - Move 'need_postvbl_update' flag to CRTC state (Daniel)
>  - Don't forget to check intermediate watermark values for validity
>(Maarten)
>  - Don't due async watermark optimization; just do it at the end of the
>atomic transaction, after waiting for vblanks.  We do want it to be
>async eventually, but adding that now will cause more trouble for
>Maarten's in-progress work.  (Maarten)
>  - Don't allocate space in crtc_state for intermediate watermarks on
>platforms that don't need it (gen9+).
>  - Move WaCxSRDisabledForSpriteScaling:ivb into intel_begin_crtc_commit
>now that ilk_update_wm is gone.
> 
> v4:
>  - Add a wm_mutex to cover updates to intel_crtc->active and the
>need_postvbl_update flag.  Since we don't have async yet it isn't
>terribly important yet, but might as well add it now.
>  - Change interface to program watermarks.  Platforms will now expose
>.initial_watermarks() and .optimize_watermarks() functions to do
>watermark programming.  These should lock wm_mutex, copy the
>appropriate state values into intel_crtc->active, and then call
>the internal program watermarks function.
> 
> v5:
>  - Skip intermediate watermark calculation/check during initial hardware
>readout since we don't trust the existing HW values (and don't have
>valid values of our own yet).
>  - Don't try to call .optimize_watermarks() on platforms that don't have
>atomic watermarks yet.  (Maarten)
> 
> v6:
>  - Rebase
> 
> v7:
>  - Further rebase
> 
> v8:
>  - A few minor indentation and line length fixes
> 
> v9:
>  - Yet another rebase since Maarten's patches reworked a bunch of the
>code (wm_pre, wm_post, etc.) that this was previously based on.
> 
> v10:
>  - Move wm_mutex to dev_priv to protect against racing commits against
>disjoint CRTC sets. (Maarten)
>  - Drop unnecessary clearing of cstate->wm.need_postvbl_update (Maarten)
> 
> v11:
>  - Now that we've moved to atomic watermark updates, make sure we call
>the proper function to program watermarks in
>{ironlake,haswell}_crtc_enable(); the failure to do so on the
>previous patch iteration led to us not actually programming the
>watermarks before turning on the CRTC, which was the cause of the
>underruns that the CI system was seeing.
>  - Fix inverted logic for determining when to optimize watermarks.  We
>were needlessly optimizing when the intermediate/optimal values were
>the same (harmless), but not actually optimizing when they differed
>(also harmless, but wasteful from a power/bandwidth perspective).
> 
> Cc: Maarten Lankhorst 
> Signed-off-by: Matt Roper 
> ---

To assist with review, the non-rebasing changes in this iteration vs the
last one are:

> @@ -4925,7 +4960,7 @@ static void ironlake_crtc_enable(struct drm_crtc *crtc)
>*/
>   intel_crtc_load_lut(crtc);
>  
> - intel_update_watermarks(crtc);
> + dev_priv->display.initial_watermarks(intel_crtc->config);
>   intel_enable_pipe(intel_crtc);
>  
>   if (intel_crtc->config->has_pch_encoder)
> @@ -5024,7 +5059,7 @@ static void haswell_crtc_enable(struct drm_crtc *crtc)
>   if (!intel_crtc->config->has_dsi_encoder)
>   intel_ddi_enable_transcoder_func(crtc);
>  
> - intel_update_watermarks(crtc);
> + dev_priv->display.initial_watermarks(pipe_config);
>   intel_enable_pipe(intel_crtc);
>  
>   if (intel_crtc->config->has_pch_encoder)

(both new additions to the patch)

and:

> + /*
> +  * If our intermediate WM are identical to the final WM, then we can
> +  * omit the post-vblank programming; only update if it's different.
> +  */
> + if (memcmp(a, >wm.optimal.ilk, sizeof(*a)) == 0)
> + newstate->wm.need_postvbl_update = false;

(replacement of a "!=" with "==")


Matt

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Add two-stage ILK-style watermark programming (v11)

[Matt Roper]

In addition to calculating final watermarks, let's also pre-calculate a
set of intermediate watermark values at atomic check time.  These
intermediate watermarks are a combination of the watermarks for the old
state and the new state; they should satisfy the requirements of both
states which means they can be programmed immediately when we commit the
atomic state (without waiting for a vblank).  Once the vblank does
happen, we can then re-program watermarks to the more optimal final
value.

v2: Significant rebasing/rewriting.

v3:
 - Move 'need_postvbl_update' flag to CRTC state (Daniel)
 - Don't forget to check intermediate watermark values for validity
   (Maarten)
 - Don't due async watermark optimization; just do it at the end of the
   atomic transaction, after waiting for vblanks.  We do want it to be
   async eventually, but adding that now will cause more trouble for
   Maarten's in-progress work.  (Maarten)
 - Don't allocate space in crtc_state for intermediate watermarks on
   platforms that don't need it (gen9+).
 - Move WaCxSRDisabledForSpriteScaling:ivb into intel_begin_crtc_commit
   now that ilk_update_wm is gone.

v4:
 - Add a wm_mutex to cover updates to intel_crtc->active and the
   need_postvbl_update flag.  Since we don't have async yet it isn't
   terribly important yet, but might as well add it now.
 - Change interface to program watermarks.  Platforms will now expose
   .initial_watermarks() and .optimize_watermarks() functions to do
   watermark programming.  These should lock wm_mutex, copy the
   appropriate state values into intel_crtc->active, and then call
   the internal program watermarks function.

v5:
 - Skip intermediate watermark calculation/check during initial hardware
   readout since we don't trust the existing HW values (and don't have
   valid values of our own yet).
 - Don't try to call .optimize_watermarks() on platforms that don't have
   atomic watermarks yet.  (Maarten)

v6:
 - Rebase

v7:
 - Further rebase

v8:
 - A few minor indentation and line length fixes

v9:
 - Yet another rebase since Maarten's patches reworked a bunch of the
   code (wm_pre, wm_post, etc.) that this was previously based on.

v10:
 - Move wm_mutex to dev_priv to protect against racing commits against
   disjoint CRTC sets. (Maarten)
 - Drop unnecessary clearing of cstate->wm.need_postvbl_update (Maarten)

v11:
 - Now that we've moved to atomic watermark updates, make sure we call
   the proper function to program watermarks in
   {ironlake,haswell}_crtc_enable(); the failure to do so on the
   previous patch iteration led to us not actually programming the
   watermarks before turning on the CRTC, which was the cause of the
   underruns that the CI system was seeing.
 - Fix inverted logic for determining when to optimize watermarks.  We
   were needlessly optimizing when the intermediate/optimal values were
   the same (harmless), but not actually optimizing when they differed
   (also harmless, but wasteful from a power/bandwidth perspective).

Cc: Maarten Lankhorst 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/i915_dma.c  |   1 +
 drivers/gpu/drm/i915/i915_drv.h  |  13 ++-
 drivers/gpu/drm/i915/intel_atomic.c  |   1 +
 drivers/gpu/drm/i915/intel_display.c |  97 +++--
 drivers/gpu/drm/i915/intel_drv.h |  28 +-
 drivers/gpu/drm/i915/intel_pm.c  | 162 ---
 6 files changed, 244 insertions(+), 58 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 1c6d227..36c0cf1 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1010,6 +1010,7 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)
mutex_init(_priv->sb_lock);
mutex_init(_priv->modeset_restore_lock);
mutex_init(_priv->av_mutex);
+   mutex_init(_priv->wm.wm_mutex);
 
ret = i915_workqueues_init(dev_priv);
if (ret < 0)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9e76bfc..cf17d62 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -631,7 +631,11 @@ struct drm_i915_display_funcs {
  struct dpll *best_clock);
int (*compute_pipe_wm)(struct intel_crtc *crtc,
   struct drm_atomic_state *state);
-   void (*program_watermarks)(struct intel_crtc_state *cstate);
+   int (*compute_intermediate_wm)(struct drm_device *dev,
+  struct intel_crtc *intel_crtc,
+  struct intel_crtc_state *newstate);
+   void (*initial_watermarks)(struct intel_crtc_state *cstate);
+   void (*optimize_watermarks)(struct intel_crtc_state *cstate);
void (*update_wm)(struct drm_crtc *crtc);
int (*modeset_calc_cdclk)(struct drm_atomic_state *state);
void 

[Intel-gfx] [PATCH] drm/i915: Resume DP MST before doing any kind of modesetting

[Lyude]

As it turns out, resuming DP MST is racey since we don't make sure MST
is ready before we start modesetting, it just usually happens to be
ready in time. This isn't the case on all systems, particularly a
ThinkPad T560 with displays connected through the dock. On these
systems, resuming the laptop while connected to the dock usually results
in blank monitors. Making sure MST is ready before doing any kind of
modesetting fixes this issue.

We originally changed the resume order in

commit e7d6f7d70829 ("drm/i915: resume MST after reading back hw state")

to fix a ton of WARN_ON's after resume, but this doesn't seem to be an
issue now anyhow.

CC: sta...@vger.kernel.org
Signed-off-by: Lyude 
---
 drivers/gpu/drm/i915/i915_drv.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index f357058..4dcf3dd 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -733,6 +733,14 @@ static int i915_drm_resume(struct drm_device *dev)
intel_opregion_setup(dev);
 
intel_init_pch_refclk(dev);
+
+   /*
+* We need to make sure that we resume MST before doing anything
+* display related, otherwise we risk trying to bring up a display on
+* MST before the hub is actually ready
+*/
+   intel_dp_mst_resume(dev);
+
drm_mode_config_reset(dev);
 
/*
@@ -765,8 +773,6 @@ static int i915_drm_resume(struct drm_device *dev)
intel_display_resume(dev);
drm_modeset_unlock_all(dev);
 
-   intel_dp_mst_resume(dev);
-
/*
 * ... but also need to make sure that hotplug processing
 * doesn't cause havoc. Like in the driver load code we don't
-- 
2.5.0

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

Re: [Intel-gfx] [PATCH v5 26/35] drm/i915: Added debugfs interface to scheduler tuning parameters

[Jesse Barnes]

On 02/18/2016 06:27 AM, john.c.harri...@intel.com wrote:
> From: John Harrison 
> 
> There are various parameters within the scheduler which can be tuned
> to improve performance, reduce memory footprint, etc. This change adds
> support for altering these via debugfs.
> 
> v2: Updated for priorities now being signed values.
> 
> v5: Squashed priority bumping entries into this patch rather than a
> separate patch all of their own.
> 
> For: VIZ-1587
> Signed-off-by: John Harrison 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 169 
> 
>  1 file changed, 169 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index b923949..7d01c07 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -39,6 +39,7 @@
>  #include "intel_ringbuffer.h"
>  #include 
>  #include "i915_drv.h"
> +#include "i915_scheduler.h"
>  
>  enum {
>   ACTIVE_LIST,
> @@ -1122,6 +1123,168 @@ DEFINE_SIMPLE_ATTRIBUTE(i915_next_seqno_fops,
>   i915_next_seqno_get, i915_next_seqno_set,
>   "0x%llx\n");
>  
> +static int
> +i915_scheduler_priority_min_get(void *data, u64 *val)
> +{
> + struct drm_device   *dev   = data;
> + struct drm_i915_private *dev_priv  = dev->dev_private;
> + struct i915_scheduler   *scheduler = dev_priv->scheduler;
> +
> + *val = (u64) scheduler->priority_level_min;
> + return 0;
> +}
> +
> +static int
> +i915_scheduler_priority_min_set(void *data, u64 val)
> +{
> + struct drm_device   *dev   = data;
> + struct drm_i915_private *dev_priv  = dev->dev_private;
> + struct i915_scheduler   *scheduler = dev_priv->scheduler;
> +
> + scheduler->priority_level_min = (int32_t) val;
> + return 0;
> +}
> +
> +DEFINE_SIMPLE_ATTRIBUTE(i915_scheduler_priority_min_fops,
> + i915_scheduler_priority_min_get,
> + i915_scheduler_priority_min_set,
> + "%lld\n");
> +
> +static int
> +i915_scheduler_priority_max_get(void *data, u64 *val)
> +{
> + struct drm_device   *dev   = data;
> + struct drm_i915_private *dev_priv  = dev->dev_private;
> + struct i915_scheduler   *scheduler = dev_priv->scheduler;
> +
> + *val = (u64) scheduler->priority_level_max;
> + return 0;
> +}
> +
> +static int
> +i915_scheduler_priority_max_set(void *data, u64 val)
> +{
> + struct drm_device   *dev   = data;
> + struct drm_i915_private *dev_priv  = dev->dev_private;
> + struct i915_scheduler   *scheduler = dev_priv->scheduler;
> +
> + scheduler->priority_level_max = (int32_t) val;
> + return 0;
> +}
> +
> +DEFINE_SIMPLE_ATTRIBUTE(i915_scheduler_priority_max_fops,
> + i915_scheduler_priority_max_get,
> + i915_scheduler_priority_max_set,
> + "%lld\n");
> +
> +static int
> +i915_scheduler_priority_bump_get(void *data, u64 *val)
> +{
> + struct drm_device   *dev   = data;
> + struct drm_i915_private *dev_priv  = dev->dev_private;
> + struct i915_scheduler   *scheduler = dev_priv->scheduler;
> +
> + *val = (u64) scheduler->priority_level_bump;
> + return 0;
> +}
> +
> +static int
> +i915_scheduler_priority_bump_set(void *data, u64 val)
> +{
> + struct drm_device   *dev   = data;
> + struct drm_i915_private *dev_priv  = dev->dev_private;
> + struct i915_scheduler   *scheduler = dev_priv->scheduler;
> +
> + scheduler->priority_level_bump = (u32) val;
> + return 0;
> +}
> +
> +DEFINE_SIMPLE_ATTRIBUTE(i915_scheduler_priority_bump_fops,
> + i915_scheduler_priority_bump_get,
> + i915_scheduler_priority_bump_set,
> + "%lld\n");
> +
> +static int
> +i915_scheduler_priority_preempt_get(void *data, u64 *val)
> +{
> + struct drm_device   *dev   = data;
> + struct drm_i915_private *dev_priv  = dev->dev_private;
> + struct i915_scheduler   *scheduler = dev_priv->scheduler;
> +
> + *val = (u64) scheduler->priority_level_preempt;
> + return 0;
> +}
> +
> +static int
> +i915_scheduler_priority_preempt_set(void *data, u64 val)
> +{
> + struct drm_device   *dev   = data;
> + struct drm_i915_private *dev_priv  = dev->dev_private;
> + struct i915_scheduler   *scheduler = dev_priv->scheduler;
> +
> + scheduler->priority_level_preempt = (u32) val;
> + return 0;
> +}
> +
> +DEFINE_SIMPLE_ATTRIBUTE(i915_scheduler_priority_preempt_fops,
> + i915_scheduler_priority_preempt_get,
> + i915_scheduler_priority_preempt_set,
> + "%lld\n");
> +
> +static int
> +i915_scheduler_min_flying_get(void *data, u64 *val)
> +{
> + struct drm_device   *dev   = data;
> + struct drm_i915_private *dev_priv  = 

Re: [Intel-gfx] [PATCH v5 25/35] drm/i915: Added scheduler queue throttling by DRM file handle

[Jesse Barnes]

On 02/18/2016 06:27 AM, john.c.harri...@intel.com wrote:
> From: John Harrison 
> 
> The scheduler decouples the submission of batch buffers to the driver
> from their subsequent submission to the hardware. This means that an
> application which is continuously submitting buffers as fast as it can
> could potentialy flood the driver. To prevent this, the driver now
> tracks how many buffers are in progress (queued in software or
> executing in hardware) and limits this to a given (tunable) number. If
> this number is exceeded then the queue to the driver will return
> EAGAIN and thus prevent the scheduler's queue becoming arbitrarily
> large.
> 
> v3: Added a missing decrement of the file queue counter.
> 
> v4: Updated a comment.
> 
> v5: Updated due to changes to earlier patches in series - removing
> forward declarations and white space. Also added some documentation.
> [Joonas Lahtinen]
> 
> For: VIZ-1587
> Signed-off-by: John Harrison 
> ---
>  drivers/gpu/drm/i915/i915_drv.h|  2 ++
>  drivers/gpu/drm/i915/i915_gem_execbuffer.c |  8 +
>  drivers/gpu/drm/i915/i915_scheduler.c  | 48 
> ++
>  drivers/gpu/drm/i915/i915_scheduler.h  |  2 ++
>  4 files changed, 60 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 071a27b..3f4c4f0 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -336,6 +336,8 @@ struct drm_i915_file_private {
>   } rps;
>  
>   struct intel_engine_cs *bsd_ring;
> +
> + u32 scheduler_queue_length;
>  };
>  
>  enum intel_dpll_id {
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index d4de8c7..dff120c 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -1803,6 +1803,10 @@ i915_gem_execbuffer(struct drm_device *dev, void *data,
>   return -EINVAL;
>   }
>  
> + /* Throttle batch requests per device file */
> + if (i915_scheduler_file_queue_is_full(file))
> + return -EAGAIN;
> +
>   /* Copy in the exec list from userland */
>   exec_list = drm_malloc_ab(sizeof(*exec_list), args->buffer_count);
>   exec2_list = drm_malloc_ab(sizeof(*exec2_list), args->buffer_count);
> @@ -1893,6 +1897,10 @@ i915_gem_execbuffer2(struct drm_device *dev, void 
> *data,
>   return -EINVAL;
>   }
>  
> + /* Throttle batch requests per device file */
> + if (i915_scheduler_file_queue_is_full(file))
> + return -EAGAIN;
> +
>   exec2_list = kmalloc(sizeof(*exec2_list)*args->buffer_count,
>GFP_TEMPORARY | __GFP_NOWARN | __GFP_NORETRY);
>   if (exec2_list == NULL)
> diff --git a/drivers/gpu/drm/i915/i915_scheduler.c 
> b/drivers/gpu/drm/i915/i915_scheduler.c
> index e56ce08..f7f29d5 100644
> --- a/drivers/gpu/drm/i915/i915_scheduler.c
> +++ b/drivers/gpu/drm/i915/i915_scheduler.c
> @@ -69,6 +69,7 @@ int i915_scheduler_init(struct drm_device *dev)
>   scheduler->priority_level_bump= 50;
>   scheduler->priority_level_preempt = 900;
>   scheduler->min_flying = 2;
> + scheduler->file_queue_max = 64;
>  
>   dev_priv->scheduler = scheduler;
>  
> @@ -464,6 +465,44 @@ static int i915_scheduler_submit_unlocked(struct 
> intel_engine_cs *ring)
>   return ret;
>  }
>  
> +/**
> + * i915_scheduler_file_queue_is_full - Returns true if the queue is full.
> + * @file: File object to query.
> + * This allows throttling of applications by limiting the total number of
> + * outstanding requests to a specified level. Once that limit is reached,
> + * this call will return true and no more requests should be accepted.
> + */
> +bool i915_scheduler_file_queue_is_full(struct drm_file *file)
> +{
> + struct drm_i915_file_private *file_priv = file->driver_priv;
> + struct drm_i915_private *dev_priv  = file_priv->dev_priv;
> + struct i915_scheduler *scheduler = dev_priv->scheduler;
> +
> + return file_priv->scheduler_queue_length >= scheduler->file_queue_max;
> +}
> +
> +/**
> + * i915_scheduler_file_queue_inc - Increment the file's request queue count.
> + * @file: File object to process.
> + */
> +static void i915_scheduler_file_queue_inc(struct drm_file *file)
> +{
> + struct drm_i915_file_private *file_priv = file->driver_priv;
> +
> + file_priv->scheduler_queue_length++;
> +}
> +
> +/**
> + * i915_scheduler_file_queue_dec - Decrement the file's request queue count.
> + * @file: File object to process.
> + */
> +static void i915_scheduler_file_queue_dec(struct drm_file *file)
> +{
> + struct drm_i915_file_private *file_priv = file->driver_priv;
> +
> + file_priv->scheduler_queue_length--;
> +}
> +
>  static void i915_generate_dependencies(struct i915_scheduler *scheduler,
>  

Re: [Intel-gfx] [PATCH v5 24/35] drm/i915: Added trace points to scheduler

[Jesse Barnes]

On 02/18/2016 06:27 AM, john.c.harri...@intel.com wrote:
> From: John Harrison 
> 
> Added trace points to the scheduler to track all the various events,
> node state transitions and other interesting things that occur.
> 
> v2: Updated for new request completion tracking implementation.
> 
> v3: Updated for changes to node kill code.
> 
> v4: Wrapped some long lines to keep the style checker happy.
> 
> For: VIZ-1587
> Signed-off-by: John Harrison 
> ---
>  drivers/gpu/drm/i915/i915_gem_execbuffer.c |   2 +
>  drivers/gpu/drm/i915/i915_scheduler.c  |  26 
>  drivers/gpu/drm/i915/i915_trace.h  | 196 
> +
>  drivers/gpu/drm/i915/intel_lrc.c   |   2 +
>  4 files changed, 226 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index b9ad0fd..d4de8c7 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -1272,6 +1272,8 @@ i915_gem_ringbuffer_submission(struct 
> i915_execbuffer_params *params,
>  
>   i915_gem_execbuffer_move_to_active(vmas, params->request);
>  
> + trace_i915_gem_ring_queue(ring, params);
> +
>   qe = container_of(params, typeof(*qe), params);
>   ret = i915_scheduler_queue_execbuffer(qe);
>   if (ret)
> diff --git a/drivers/gpu/drm/i915/i915_scheduler.c 
> b/drivers/gpu/drm/i915/i915_scheduler.c
> index 47d7de4..e56ce08 100644
> --- a/drivers/gpu/drm/i915/i915_scheduler.c
> +++ b/drivers/gpu/drm/i915/i915_scheduler.c
> @@ -88,6 +88,8 @@ static void i915_scheduler_node_requeue(struct 
> i915_scheduler_queue_entry *node)
>   /* Seqno will be reassigned on relaunch */
>   node->params.request->seqno = 0;
>   node->status = i915_sqs_queued;
> + trace_i915_scheduler_unfly(node->params.ring, node);
> + trace_i915_scheduler_node_state_change(node->params.ring, node);
>  }
>  
>  /*
> @@ -99,7 +101,11 @@ static void i915_scheduler_node_kill(struct 
> i915_scheduler_queue_entry *node)
>   WARN_ON(!node);
>   WARN_ON(I915_SQS_IS_COMPLETE(node));
>  
> + if (I915_SQS_IS_FLYING(node))
> + trace_i915_scheduler_unfly(node->params.ring, node);
> +
>   node->status = i915_sqs_dead;
> + trace_i915_scheduler_node_state_change(node->params.ring, node);
>  }
>  
>  /* Mark a node as in flight on the hardware. */
> @@ -124,6 +130,9 @@ static int i915_scheduler_node_fly(struct 
> i915_scheduler_queue_entry *node)
>  
>   node->status = i915_sqs_flying;
>  
> + trace_i915_scheduler_fly(ring, node);
> + trace_i915_scheduler_node_state_change(ring, node);
> +
>   if (!(scheduler->flags[ring->id] & i915_sf_interrupts_enabled)) {
>   bool success = true;
>  
> @@ -280,6 +289,8 @@ static int i915_scheduler_pop_from_queue_locked(struct 
> intel_engine_cs *ring,
>   INIT_LIST_HEAD(>link);
>   best->status  = i915_sqs_popped;
>  
> + trace_i915_scheduler_node_state_change(ring, best);
> +
>   ret = 0;
>   } else {
>   /* Can only get here if:
> @@ -297,6 +308,8 @@ static int i915_scheduler_pop_from_queue_locked(struct 
> intel_engine_cs *ring,
>   }
>   }
>  
> + trace_i915_scheduler_pop_from_queue(ring, best);
> +
>   *pop_node = best;
>   return ret;
>  }
> @@ -506,6 +519,8 @@ static int i915_scheduler_queue_execbuffer_bypass(struct 
> i915_scheduler_queue_en
>   struct i915_scheduler *scheduler = dev_priv->scheduler;
>   int ret;
>  
> + trace_i915_scheduler_queue(qe->params.ring, qe);
> +
>   intel_ring_reserved_space_cancel(qe->params.request->ringbuf);
>  
>   scheduler->flags[qe->params.ring->id] |= i915_sf_submitting;
> @@ -628,6 +643,9 @@ int i915_scheduler_queue_execbuffer(struct 
> i915_scheduler_queue_entry *qe)
>   not_flying = i915_scheduler_count_flying(scheduler, ring) <
>scheduler->min_flying;
>  
> + trace_i915_scheduler_queue(ring, node);
> + trace_i915_scheduler_node_state_change(ring, node);
> +
>   spin_unlock_irq(>lock);
>  
>   if (not_flying)
> @@ -657,6 +675,8 @@ bool i915_scheduler_notify_request(struct 
> drm_i915_gem_request *req)
>   struct i915_scheduler_queue_entry *node = req->scheduler_qe;
>   unsigned long flags;
>  
> + trace_i915_scheduler_landing(req);
> +
>   if (!node)
>   return false;
>  
> @@ -670,6 +690,8 @@ bool i915_scheduler_notify_request(struct 
> drm_i915_gem_request *req)
>   else
>   node->status = i915_sqs_complete;
>  
> + trace_i915_scheduler_node_state_change(req->ring, node);
> +
>   spin_unlock_irqrestore(>lock, flags);
>  
>   return true;
> @@ -877,6 +899,8 @@ static bool i915_scheduler_remove(struct i915_scheduler 
> *scheduler,
>   /* Launch more packets now? */
>   do_submit = (queued > 

Re: [Intel-gfx] [PATCH v5 24/35] drm/i915: Added trace points to scheduler

[Jesse Barnes]

On 02/18/2016 06:27 AM, john.c.harri...@intel.com wrote:
> From: John Harrison 
> 
> Added trace points to the scheduler to track all the various events,
> node state transitions and other interesting things that occur.
> 
> v2: Updated for new request completion tracking implementation.
> 
> v3: Updated for changes to node kill code.
> 
> v4: Wrapped some long lines to keep the style checker happy.
> 
> For: VIZ-1587
> Signed-off-by: John Harrison 
> ---
>  drivers/gpu/drm/i915/i915_gem_execbuffer.c |   2 +
>  drivers/gpu/drm/i915/i915_scheduler.c  |  26 
>  drivers/gpu/drm/i915/i915_trace.h  | 196 
> +
>  drivers/gpu/drm/i915/intel_lrc.c   |   2 +
>  4 files changed, 226 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index b9ad0fd..d4de8c7 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -1272,6 +1272,8 @@ i915_gem_ringbuffer_submission(struct 
> i915_execbuffer_params *params,
>  
>   i915_gem_execbuffer_move_to_active(vmas, params->request);
>  
> + trace_i915_gem_ring_queue(ring, params);
> +
>   qe = container_of(params, typeof(*qe), params);
>   ret = i915_scheduler_queue_execbuffer(qe);
>   if (ret)
> diff --git a/drivers/gpu/drm/i915/i915_scheduler.c 
> b/drivers/gpu/drm/i915/i915_scheduler.c
> index 47d7de4..e56ce08 100644
> --- a/drivers/gpu/drm/i915/i915_scheduler.c
> +++ b/drivers/gpu/drm/i915/i915_scheduler.c
> @@ -88,6 +88,8 @@ static void i915_scheduler_node_requeue(struct 
> i915_scheduler_queue_entry *node)
>   /* Seqno will be reassigned on relaunch */
>   node->params.request->seqno = 0;
>   node->status = i915_sqs_queued;
> + trace_i915_scheduler_unfly(node->params.ring, node);
> + trace_i915_scheduler_node_state_change(node->params.ring, node);
>  }
>  
>  /*
> @@ -99,7 +101,11 @@ static void i915_scheduler_node_kill(struct 
> i915_scheduler_queue_entry *node)
>   WARN_ON(!node);
>   WARN_ON(I915_SQS_IS_COMPLETE(node));
>  
> + if (I915_SQS_IS_FLYING(node))
> + trace_i915_scheduler_unfly(node->params.ring, node);
> +
>   node->status = i915_sqs_dead;
> + trace_i915_scheduler_node_state_change(node->params.ring, node);
>  }
>  
>  /* Mark a node as in flight on the hardware. */
> @@ -124,6 +130,9 @@ static int i915_scheduler_node_fly(struct 
> i915_scheduler_queue_entry *node)
>  
>   node->status = i915_sqs_flying;
>  
> + trace_i915_scheduler_fly(ring, node);
> + trace_i915_scheduler_node_state_change(ring, node);
> +
>   if (!(scheduler->flags[ring->id] & i915_sf_interrupts_enabled)) {
>   bool success = true;
>  
> @@ -280,6 +289,8 @@ static int i915_scheduler_pop_from_queue_locked(struct 
> intel_engine_cs *ring,
>   INIT_LIST_HEAD(>link);
>   best->status  = i915_sqs_popped;
>  
> + trace_i915_scheduler_node_state_change(ring, best);
> +
>   ret = 0;
>   } else {
>   /* Can only get here if:
> @@ -297,6 +308,8 @@ static int i915_scheduler_pop_from_queue_locked(struct 
> intel_engine_cs *ring,
>   }
>   }
>  
> + trace_i915_scheduler_pop_from_queue(ring, best);
> +
>   *pop_node = best;
>   return ret;
>  }
> @@ -506,6 +519,8 @@ static int i915_scheduler_queue_execbuffer_bypass(struct 
> i915_scheduler_queue_en
>   struct i915_scheduler *scheduler = dev_priv->scheduler;
>   int ret;
>  
> + trace_i915_scheduler_queue(qe->params.ring, qe);
> +
>   intel_ring_reserved_space_cancel(qe->params.request->ringbuf);
>  
>   scheduler->flags[qe->params.ring->id] |= i915_sf_submitting;
> @@ -628,6 +643,9 @@ int i915_scheduler_queue_execbuffer(struct 
> i915_scheduler_queue_entry *qe)
>   not_flying = i915_scheduler_count_flying(scheduler, ring) <
>scheduler->min_flying;
>  
> + trace_i915_scheduler_queue(ring, node);
> + trace_i915_scheduler_node_state_change(ring, node);
> +
>   spin_unlock_irq(>lock);
>  
>   if (not_flying)
> @@ -657,6 +675,8 @@ bool i915_scheduler_notify_request(struct 
> drm_i915_gem_request *req)
>   struct i915_scheduler_queue_entry *node = req->scheduler_qe;
>   unsigned long flags;
>  
> + trace_i915_scheduler_landing(req);
> +
>   if (!node)
>   return false;
>  
> @@ -670,6 +690,8 @@ bool i915_scheduler_notify_request(struct 
> drm_i915_gem_request *req)
>   else
>   node->status = i915_sqs_complete;
>  
> + trace_i915_scheduler_node_state_change(req->ring, node);
> +
>   spin_unlock_irqrestore(>lock, flags);
>  
>   return true;
> @@ -877,6 +899,8 @@ static bool i915_scheduler_remove(struct i915_scheduler 
> *scheduler,
>   /* Launch more packets now? */
>   do_submit = (queued > 

Re: [Intel-gfx] [PATCH v5 21/35] drm/i915: Added a module parameter to allow the scheduler to be disabled

[Jesse Barnes]

On 02/18/2016 06:27 AM, john.c.harri...@intel.com wrote:
> From: John Harrison 
> 
> It can be useful to be able to disable the GPU scheduler via a module
> parameter for debugging purposes.
> 
> v5: Converted from a multi-feature 'overrides' mask to a single
> 'enable' boolean. Further features (e.g. pre-emption) will now be
> separate 'enable' booleans added later. [Chris Wilson]
> 
> For: VIZ-1587
> Signed-off-by: John Harrison 
> ---
>  drivers/gpu/drm/i915/i915_params.c| 4 
>  drivers/gpu/drm/i915/i915_params.h| 1 +
>  drivers/gpu/drm/i915/i915_scheduler.c | 5 -
>  3 files changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_params.c 
> b/drivers/gpu/drm/i915/i915_params.c
> index d0eba58..0ef3159 100644
> --- a/drivers/gpu/drm/i915/i915_params.c
> +++ b/drivers/gpu/drm/i915/i915_params.c
> @@ -57,6 +57,7 @@ struct i915_params i915 __read_mostly = {
>   .edp_vswing = 0,
>   .enable_guc_submission = true,
>   .guc_log_level = -1,
> + .enable_scheduler = 0,
>  };
>  
>  module_param_named(modeset, i915.modeset, int, 0400);
> @@ -203,3 +204,6 @@ MODULE_PARM_DESC(enable_guc_submission, "Enable GuC 
> submission (default:false)")
>  module_param_named(guc_log_level, i915.guc_log_level, int, 0400);
>  MODULE_PARM_DESC(guc_log_level,
>   "GuC firmware logging level (-1:disabled (default), 0-3:enabled)");
> +
> +module_param_named_unsafe(enable_scheduler, i915.enable_scheduler, int, 
> 0600);
> +MODULE_PARM_DESC(enable_scheduler, "Enable scheduler (0 = disable [default], 
> 1 = enable)");
> diff --git a/drivers/gpu/drm/i915/i915_params.h 
> b/drivers/gpu/drm/i915/i915_params.h
> index 5299290..f855c86 100644
> --- a/drivers/gpu/drm/i915/i915_params.h
> +++ b/drivers/gpu/drm/i915/i915_params.h
> @@ -60,6 +60,7 @@ struct i915_params {
>   bool enable_guc_submission;
>   bool verbose_state_checks;
>   bool nuclear_pageflip;
> + int enable_scheduler;
>  };
>  
>  extern struct i915_params i915 __read_mostly;
> diff --git a/drivers/gpu/drm/i915/i915_scheduler.c 
> b/drivers/gpu/drm/i915/i915_scheduler.c
> index 4f25bf2..47d7de4 100644
> --- a/drivers/gpu/drm/i915/i915_scheduler.c
> +++ b/drivers/gpu/drm/i915/i915_scheduler.c
> @@ -34,6 +34,9 @@ bool i915_scheduler_is_enabled(struct drm_device *dev)
>  {
>   struct drm_i915_private *dev_priv = dev->dev_private;
>  
> + if (!i915.enable_scheduler)
> + return false;
> +
>   return dev_priv->scheduler != NULL;
>  }
>  
> @@ -548,7 +551,7 @@ int i915_scheduler_queue_execbuffer(struct 
> i915_scheduler_queue_entry *qe)
>  
>   WARN_ON(!scheduler);
>  
> - if (1/*!i915.enable_scheduler*/)
> + if (!i915.enable_scheduler)
>   return i915_scheduler_queue_execbuffer_bypass(qe);
>  
>   node = kmalloc(sizeof(*node), GFP_KERNEL);
> 

I did a double take here; maybe a comment along the lines of "if the scheduler 
is disabled, queue the buffer immediately" would help, and something similar 
for where the if (1) is added temporarily.

Doesn't matter too much though.

Reviewed-by: Jesse Barnes 

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

Re: [Intel-gfx] [PATCH v5 22/35] drm/i915: Support for 'unflushed' ring idle

[Jesse Barnes]

On 02/18/2016 06:27 AM, john.c.harri...@intel.com wrote:
> From: John Harrison 
> 
> When the seqno wraps around zero, the entire GPU is forced to be idle
> for some reason (possibly only to work around issues with hardware
> semaphores but no-one seems too sure!). This causes a problem if the
> force idle occurs at an inopportune moment such as in the middle of
> submitting a batch buffer. Specifically, it would lead to recursive
> submits - submitting work requires a new seqno, the new seqno requires
> idling the ring, idling the ring requires submitting work, submitting
> work requires a new seqno...
> 
> This change adds a 'flush' parameter to the idle function call which
> specifies whether the scheduler queues should be flushed out. I.e. is
> the call intended to just idle the ring as it is right now (no flush)
> or is it intended to force all outstanding work out of the system
> (with flush).
> 
> In the seqno wrap case, pending work is not an issue because the next
> operation will be to submit it. However, in other cases, the intention
> is to make sure everything that could be done has been done.
> 
> For: VIZ-1587
> Signed-off-by: John Harrison 
> ---
>  drivers/gpu/drm/i915/i915_gem.c |  4 ++--
>  drivers/gpu/drm/i915/intel_lrc.c|  2 +-
>  drivers/gpu/drm/i915/intel_ringbuffer.c | 17 +++--
>  drivers/gpu/drm/i915/intel_ringbuffer.h |  2 +-
>  4 files changed, 19 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index d7f7f7a..a249e52 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2564,7 +2564,7 @@ i915_gem_init_seqno(struct drm_device *dev, u32 seqno)
>  
>   /* Carefully retire all requests without writing to the rings */
>   for_each_ring(ring, dev_priv, i) {
> - ret = intel_ring_idle(ring);
> + ret = intel_ring_idle(ring, false);
>   if (ret)
>   return ret;
>   }
> @@ -3808,7 +3808,7 @@ int i915_gpu_idle(struct drm_device *dev)
>   i915_add_request_no_flush(req);
>   }
>  
> - ret = intel_ring_idle(ring);
> + ret = intel_ring_idle(ring, true);
>   if (ret)
>   return ret;
>   }
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index f4bab82..e056875 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -1058,7 +1058,7 @@ void intel_logical_ring_stop(struct intel_engine_cs 
> *ring)
>   if (!intel_ring_initialized(ring))
>   return;
>  
> - ret = intel_ring_idle(ring);
> + ret = intel_ring_idle(ring, true);
>   if (ret && !i915_reset_in_progress(_i915(ring->dev)->gpu_error))
>   DRM_ERROR("failed to quiesce %s whilst cleaning up: %d\n",
> ring->name, ret);
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index a2093f5..70ef9f0 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -2288,9 +2288,22 @@ static void __wrap_ring_buffer(struct intel_ringbuffer 
> *ringbuf)
>   intel_ring_update_space(ringbuf);
>  }
>  
> -int intel_ring_idle(struct intel_engine_cs *ring)
> +int intel_ring_idle(struct intel_engine_cs *ring, bool flush)
>  {
>   struct drm_i915_gem_request *req;
> + int ret;
> +
> + /*
> +  * NB: Must not flush the scheduler if this idle request is from
> +  * within an execbuff submission (i.e. due to 'get_seqno' calling
> +  * 'wrap_seqno' calling 'idle'). As that would lead to recursive
> +  * flushes!
> +  */
> + if (flush) {
> + ret = i915_scheduler_flush(ring, true);
> + if (ret)
> + return ret;
> + }
>  
>   /* Wait upon the last request to be completed */
>   if (list_empty(>request_list))
> @@ -3095,7 +3108,7 @@ intel_stop_ring_buffer(struct intel_engine_cs *ring)
>   if (!intel_ring_initialized(ring))
>   return;
>  
> - ret = intel_ring_idle(ring);
> + ret = intel_ring_idle(ring, true);
>   if (ret && !i915_reset_in_progress(_i915(ring->dev)->gpu_error))
>   DRM_ERROR("failed to quiesce %s whilst cleaning up: %d\n",
> ring->name, ret);
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
> b/drivers/gpu/drm/i915/intel_ringbuffer.h
> index ada93a9..cca476f 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.h
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
> @@ -478,7 +478,7 @@ void intel_ring_update_space(struct intel_ringbuffer 
> *ringbuf);
>  int intel_ring_space(struct intel_ringbuffer *ringbuf);
>  bool intel_ring_stopped(struct intel_engine_cs *ring);
>  
> -int __must_check intel_ring_idle(struct intel_engine_cs 

Re: [Intel-gfx] [PATCH v5 20/35] drm/i915: Add scheduler hook to GPU reset

[Jesse Barnes]

On 02/18/2016 06:27 AM, john.c.harri...@intel.com wrote:
> From: John Harrison 
> 
> When the watchdog resets the GPU, all interrupts get disabled despite
> the reference count remaining. As the scheduler probably had
> interrupts enabled during the reset (it would have been waiting for
> the bad batch to complete), it must be poked to tell it that the
> interrupt has been disabled.
> 
> v5: New patch in series.
> 
> For: VIZ-1587
> Signed-off-by: John Harrison 
> ---
>  drivers/gpu/drm/i915/i915_gem.c   |  2 ++
>  drivers/gpu/drm/i915/i915_scheduler.c | 11 +++
>  drivers/gpu/drm/i915/i915_scheduler.h |  1 +
>  3 files changed, 14 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index d946f53..d7f7f7a 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3248,6 +3248,8 @@ static void i915_gem_reset_ring_cleanup(struct 
> drm_i915_private *dev_priv,
>   buffer->last_retired_head = buffer->tail;
>   intel_ring_update_space(buffer);
>   }
> +
> + i915_scheduler_reset_cleanup(ring);
>  }
>  
>  void i915_gem_reset(struct drm_device *dev)
> diff --git a/drivers/gpu/drm/i915/i915_scheduler.c 
> b/drivers/gpu/drm/i915/i915_scheduler.c
> index 8130a9c..4f25bf2 100644
> --- a/drivers/gpu/drm/i915/i915_scheduler.c
> +++ b/drivers/gpu/drm/i915/i915_scheduler.c
> @@ -778,6 +778,17 @@ void i915_scheduler_clean_node(struct 
> i915_scheduler_queue_entry *node)
>   }
>  }
>  
> +void i915_scheduler_reset_cleanup(struct intel_engine_cs *ring)
> +{
> + struct drm_i915_private *dev_priv = ring->dev->dev_private;
> + struct i915_scheduler *scheduler = dev_priv->scheduler;
> +
> + if (scheduler->flags[ring->id] & i915_sf_interrupts_enabled) {
> + ring->irq_put(ring);
> + scheduler->flags[ring->id] &= ~i915_sf_interrupts_enabled;
> + }
> +}
> +

So I guess these flags are also protected by the struct_mutex?  If so, I guess 
it looks ok.

Reviewed-by: Jesse Barnes 

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

Re: [Intel-gfx] [BUG] HDMI 12bpc causing occasional flickering and blanking

[Tore Anderson]

Hi Ville,

> "The monitor is connected with a DP+-to-HDMI cable"
> This and some reading of the DP dual mode spec gave me another idea;
> The DP->HDMI adaptor may simply be degrading the signal quality too
> much. According to the DP dual mode spec we're supposed to limit the
> TMDS clock based on the type of adapter used, but currently we have
> no code to do that. I've cooked up a few patches that should do what
> we want:
> git://github.com/vsyrjala/linux.git dp_dual_mode
> 
> I've quickly tested it locally, and it seemed to do the right thing
> with a few different types of adaptors.

I've run 32fa589 for a few hours now and it have not seen a single
blank or flicker. So it seems you've nailed it - thanks a lot!

Let me know if you want me to test more patches, post debug logs, or
anything else.

BTW, also discovered right before you sent that e-mail that downgrading
to a 1920x1080i mode (rather than the monitor's native 1920x1080) would
also stop the flickering. I'd assume that also fits well with your
diagnosis (less bandwidth needed => better tolerance for degraded signal
quality), but I thought I'd let you know in case not.

> > By the way: Is it possible to disable HDMI 12bpc in a way that
> > doesn't require me to patch and rebuild the kernel drivers, such as
> > a kernel module parameter or sysfs setting? (I prefer to simply use
> > the upstream Fedora kernel RPMs, but this issue is currently making
> > that impossible.)  
> 
> We don't have any knob to control this.

I don't need it anymore, so no worries. ;-)

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

Re: [Intel-gfx] [PATCH v2] drm/i915: Avoid selecting unavailable BSD2 ring

[Dave Gordon]

On 23/02/16 14:39, Tvrtko Ursulin wrote:


On 23/02/16 14:03, Chris Wilson wrote:

On Tue, Feb 23, 2016 at 01:31:17PM +, Tvrtko Ursulin wrote:


On 23/02/16 13:06, Gabriel Feceoru wrote:



On 23.02.2016 13:05, Tvrtko Ursulin wrote:


Hi,

On 23/02/16 10:52, Gabriel Feceoru wrote:

Return error when I915_EXEC_BSD_RING2 flag is set but BSD2 ring
is not available in the HW.


What is the reasoning behind this? So far kernel was allowing
userspace
to select these bits and execute on the first engine. With this
patch it
would start failing potentially breaking userspace. Is it not too late
to make such change?


I noticed some inconsistencies in igt with regards to bsd and bsd1.
For instance, if bsd2 is not available, gem_sync@basic-bsd1 is skipped,
but it's skipped because of the 2nd check gem_has_bsd2 (see
gem_require_ring). Surprisingly gem_has_ring() didn't complain about
bsd1.

This fix will make gem_has_ring() return false.

I'm not aware about legacy/compatibility issue - if that's the case,
please disregard this.


Hmmm.. Chris, what is the reasoning behind:

commit eaa03678b00179da89f194113c0740c033857c1c
Author: Chris Wilson 
Date:   Thu Jan 28 13:44:19 2016 +

 lib: Hide BSD1/BSD2 rings on hardware without BSD2

 The kernel happily lets us run on I915_EXEC_BSD2 even with such
hardware
 existing. Sigh.

 Signed-off-by: Chris Wilson 

diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
index 9dfa9b2603ce..fa44080e5902 100644
--- a/lib/ioctl_wrappers.c
+++ b/lib/ioctl_wrappers.c
@@ -1341,6 +1341,12 @@ static int gem_has_ring(int fd, int ring)
  void gem_require_ring(int fd, int ring_id)
  {
 igt_require(gem_has_ring(fd, ring_id));
+
+   /* silly ABI, the kernel thinks everyone who has BSD also has
BSD2 */
+   if ((ring_id & ~(3<<13)) == I915_EXEC_BSD) {
+   if (ring_id & (3 << 13))
+   igt_require(gem_has_bsd2(fd));
+   }
  }

  /* prime */

ABI was (and still is) that specifying BSD1 or BSD2 explicitly is
silently ignored by the kernel when BSD2 is not preset, defaulting
to BSD1.


Thereby pretending that BSD, BSD1, BSD2 exist.


This patch makes tests requesting BSD1 skip when there is no BSD2
which I think is wrong in any case.


BSD 1/2 selection only makes sense when we have multiple BSD rings.
Running tests on BSD default, BSD1 and BSD2 is pointless if they all
are equivalent. Using the BSD ping-pong when we have BSD1 and BSD2 is
questionable as the ping-pong nature is uncontrolled, but nevertheless
the code path needs to be tested.


If we want to (and can) change the ABI it should only reject the
non-existent ring and not limit the selection mechanism to
hardware which has BSD2.


I disagree, we have a ring selection mechanism. If the extension doesn't
exist, trying to use it should be an error. The extension was not only
an ABI mistake but undesired (it is now defunct).


Not sure that I understand what you meant here. Nothing as far as I can
tell is now defunct. Neither the selection mechanism, or the existence
of BSD2.

To be absolutely clear, you are, or you are not, in favour of Gabriel's
patch to start failing execbuf with fine grained BSD selection flags
when BSD2 is not present?

Regards,
Tvrtko


Currently:

#define I915_EXEC_BSD (2<<0)

/** Used for switching BSD rings on the platforms with two BSD rings */
#define I915_EXEC_BSD_SHIFT   (13)
#define I915_EXEC_BSD_MASK(3 << I915_EXEC_BSD_SHIFT) /* default 
ping-pong mode */

#define I915_EXEC_BSD_DEFAULT (0 << I915_EXEC_BSD_SHIFT)
#define I915_EXEC_BSD_RING1   (1 << I915_EXEC_BSD_SHIFT)
#define I915_EXEC_BSD_RING2   (2 << I915_EXEC_BSD_SHIFT)

It makes sense to have the original "BSD" flag mean "the default BSD", 
and use different flags to mean specifically "BSD1" or "BSD2". Which 
appears to be what we've done; naive clients that don't set any of the 
new BSD bits will get default behaviour (execute on *any* BSD ring) with 
no control over the ping-pong mechanism (if any). Clients that specify a 
specific ring should get that one, and only that one; if it doesn't 
exist then it's an error.


Any program that's going to set these bits should first ask whether (or 
which) engines exist and select appropriately. So I think I'm with Chris 
here.


On the other hand, I think what Tvrtko said was "it should not be an 
error to select a specific ring [that exists] just because there are no 
other rings". Which I also agree with.


So the ring-select-checking code should:
1. reject the I915_EXEC_BSD_RING2 case if BSD2 does not exist
2. reject the I915_EXEC_BSD_RING1 case if BSD1 does not exist
 (for some future bizarre numbering scheme? or a
  partitioning system that reserves BSD1 for someone else?)
3. never reject the I915_EXEC_BSD_DEFAULT case
 (although it will have rejected the I915_EXEC_BSD flag
  before looking at these if there is no BSD ring at all)
4. for now (until we 

Re: [Intel-gfx] [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915

[Martin Kepplinger]

Am 2016-02-23 um 18:14 schrieb Ville Syrjälä:
> On Tue, Feb 23, 2016 at 05:57:40PM +0100, Takashi Iwai wrote:
>> On Mon, 22 Feb 2016 22:37:28 +0100,
>> Martin Kepplinger wrote:
>>>
>>> Am 2016-02-22 um 20:10 schrieb Takashi Iwai:
 On Mon, 22 Feb 2016 19:58:18 +0100,
 Martin Kepplinger wrote:
>
> Am 2016-02-22 um 15:12 schrieb Takashi Iwai:
>> On Mon, 22 Feb 2016 15:02:56 +0100,
>> Martin Kepplinger wrote:
 And how about my questions in the previous mail?  Does
 i915_audio_component_get_eld() is called and returns 0?
 And is monitor_present set true or false?
>>>
>>> i915_audio_component_get_eld() returns 0 and monitor_present is 0.

 If i915_audio_component_get_eld() is called but returns zero, track
 the code flow there.  It means either intel_encoder is NULL or
 intel_dig_port->audio_connector is NULL.
>>>
>>> intel_dig_port->audio_connector is NULL!
>>>
>>> (when called during boot and during HDMI plugin)
>>
>> Interesting.  The relevant code flow should be like:
>>
>>   intel_audio_codec_enable()
>>   -> acomp->audio_ops->pin_eld_notify()
>> -> intel_pin_eld_notify()
>>   -> check_presence_and_report()
>> -> hdmi_present_sense()
>>-> sync_eld_via_acomp()
>>  -> snd_hdac_acomp_get_eld()
>>-> i915_audio_component_get_eld()
>>
>> So, at first, check whether intel_dig_port in both
>> intel_audio_codec_enable() and i915_audio_component_get_eld() points
>> to the same object address.  The audio_connector must be set in
>> intel_audio_codec_enable(), thus basically it must be non-NULL at
>> i915_audio_component_get_eld(), too.
>>
>
> intel_dig_port is *not* the same object in these 2 places. During
> plugin, see:
>
> [  146.934091] in intel_audio_codec_enable: intel_dig_port is
> 8800a1f54000
> [  146.934121] in i915_audio_component_get_eld: intel_dig_port is
> 880244f7d000
>
> sorry for the slow responses. I'll try to go back that direction unless
> again someone comes up with other suggestions.

 Thanks, this makes sense.  It implies that the digital port mapping is
 somehow wrong.  There are three places setting dig_port_map[], one in
 intel_ddi_init(), one in intel_dp_init() and another in
 intel_hdmi_init().  Try to check which function creates which object
 assigned to which port number, together with drm.debug=0x0e debug
 messages.

>>> without using drm.debug=0x0e, but by printing the kmalloc'ed objects in
>>> those 3 functions with ports, I found:
>>>
>>> 2 of them are running, only during boot:
>>>
>>> [2.322865] intel_hdmi_init: intel_dig_port is 880242564000  port 1
>>> [2.322999] intel_dp_init: intel_dig_port is 880242f3  port 1
>>>
>>> is is correct for them to have both port 1? Any more ideas?
>>
>> Adding intel-gfx ML to Cc.
>>
>> Martin, is the machine SandyBridge or IvyBridge?
>>
>> In anyway it's PCH_SPLIT and there can call both intel_hdmi_init() and 
>> intel_dp_init() for the same port although both functions map
>> intel_dig_port[].  The assumption of intel_dig_port[] reverse mapping
>> is that there is only a single intel_dig_port assigned to a port, but
>> this doesn't look correct...
> 
> On pre-HSW there can indeed be two encoders for the same port.
> And I'm planning to change HSW+ to follow that model as well,
> but I've been busy with other stuff to finish off that work [1]
> 
> [1] https://lists.freedesktop.org/archives/intel-gfx/2015-December/082384.html
> 

So your work wouldn't fix hdmi-audio pre-HSW here?


Anyways, a quick fix would be good, and if not that, remember marking
future changes that fix this, for stable.

What implications would something like the following, that Takashi
suggested, have on other systems?

commit 7b20983c02928c55377b3cfa927257a17896ecee
Author: Martin Kepplinger 
Date:   Tue Feb 23 18:29:05 2016 +0100

sound: pci: hda: set codec_has_acomp to false due to pending regression

v4.5 and it's significant intel hda changes break audio over HDMI
for some cases. This is a temporary workaround to be reverted in
the future.

Signed-off-by: Martin Kepplinger 

diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c
index 8ee78db..6d6f104 100644
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -156,7 +156,7 @@ struct hdmi_spec {
bool i915_bound; /* was i915 bound in this driver? */
 };

-#ifdef CONFIG_SND_HDA_I915
+#if 0
 #define codec_has_acomp(codec) \
((codec)->bus->core.audio_component != NULL)
 #else

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

Re: [Intel-gfx] [PATCH 2/5] drm/i915: Do not read GAMMA_MODE register

[Matt Roper]

On Tue, Feb 23, 2016 at 10:36:36AM +, Lionel Landwerlin wrote:
> On 23/02/16 00:38, Matt Roper wrote:
> >On Mon, Feb 22, 2016 at 02:18:08PM +, Lionel Landwerlin wrote:
> >>Implement Daniel Stone's recommendation to not read registers to infer
> >>the hardware's state.
> >>
> >>Signed-off-by: Lionel Landwerlin 
> >Do we need to ensure that software and hardware state are synchronized
> >at startup?  A boot firmware might have set it to something different
> >before our driver starts up; if we use 'fastboot' then we might not do
> >any modesets and might wind up with 0 (8BIT) in our state variable, but
> >something else actually programmed into the hardware.
> >
> >
> >Matt
> 
> Thanks Matt,
> 
> It makes sense know, I couldn't understand why this would ever be at
> something different that 8bit mode...
> I guess the value should be read from the intel_color_init()
> function upon startup.

We have a hardware state readout where we reconstruct the hardware state
for various things like plane state and such; you could add color
management readout to that.  Alternatively, we could just force
known-good values into the hardware at startup as we do (or will very
soon) for stuff we don't trust the BIOS to get right like watermarks.


Matt

> 
> -
> Lionel

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm: DP++ adaptor support

[Patchwork]

== Series Details ==

Series: drm: DP++ adaptor support
URL   : https://patchwork.freedesktop.org/series/3735/
State : warning

== Summary ==

Series 3735v1 drm: DP++ adaptor support
http://patchwork.freedesktop.org/api/1.0/series/3735/revisions/1/mbox/

Test gem_cs_prefetch:
Subgroup basic-default:
incomplete -> PASS   (ilk-hp8440p)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass   -> DMESG-WARN (ilk-hp8440p) UNSTABLE
Test kms_force_connector_basic:
Subgroup force-edid:
skip   -> PASS   (snb-x220t)
Subgroup force-load-detect:
dmesg-fail -> FAIL   (snb-x220t)
dmesg-fail -> FAIL   (snb-dellxps)
dmesg-fail -> FAIL   (hsw-gt2)
fail   -> DMESG-FAIL (ilk-hp8440p)
Subgroup prune-stale-modes:
pass   -> SKIP   (ilk-hp8440p)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-c:
pass   -> DMESG-WARN (ivb-t430s)
Test pm_rpm:
Subgroup basic-rte:
pass   -> DMESG-WARN (bsw-nuc-2)

bdw-nuci7total:165  pass:154  dwarn:0   dfail:0   fail:0   skip:11 
bdw-ultratotal:168  pass:154  dwarn:0   dfail:0   fail:0   skip:14 
bsw-nuc-2total:168  pass:136  dwarn:1   dfail:0   fail:1   skip:30 
byt-nuc  total:168  pass:142  dwarn:1   dfail:0   fail:0   skip:25 
hsw-gt2  total:168  pass:157  dwarn:0   dfail:0   fail:1   skip:10 
ilk-hp8440p  total:168  pass:116  dwarn:1   dfail:1   fail:0   skip:50 
ivb-t430stotal:168  pass:152  dwarn:1   dfail:0   fail:1   skip:14 
snb-dellxps  total:168  pass:145  dwarn:0   dfail:0   fail:1   skip:22 
snb-x220ttotal:168  pass:145  dwarn:0   dfail:0   fail:2   skip:21 

Results at /archive/results/CI_IGT_test/Patchwork_1468/

08fc1b101049694778bff7559e1d05250d2e7072 drm-intel-nightly: 
2016y-02m-22d-17h-30m-27s UTC integration manifest
05bb77f0fe7066499d2a5d84f5f9b84972c558fd drm/i915: Determine DP++ type 1 DVI 
adaptor presence based on VBT
adb14e9638f527e31c900b459cc302ff08de7db9 drm/i915: Enable/disable TMDS output 
buffers in DP++ adaptor as needed
637d45111be8a054f30f5bbb019cc70c74f7f9c5 drm/i915: Respect DP++ adaptor TMDS 
clock limit
5682fbc251a05fbad3306834c761cc59607f8c62 drm: Add helper for DP++ adaptors

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

Re: [Intel-gfx] [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915

[Martin Kepplinger]

Am 2016-02-23 um 17:57 schrieb Takashi Iwai:
> On Mon, 22 Feb 2016 22:37:28 +0100,
> Martin Kepplinger wrote:
>>
>> Am 2016-02-22 um 20:10 schrieb Takashi Iwai:
>>> On Mon, 22 Feb 2016 19:58:18 +0100,
>>> Martin Kepplinger wrote:

 Am 2016-02-22 um 15:12 schrieb Takashi Iwai:
> On Mon, 22 Feb 2016 15:02:56 +0100,
> Martin Kepplinger wrote:
>>> And how about my questions in the previous mail?  Does
>>> i915_audio_component_get_eld() is called and returns 0?
>>> And is monitor_present set true or false?
>>
>> i915_audio_component_get_eld() returns 0 and monitor_present is 0.
>>>
>>> If i915_audio_component_get_eld() is called but returns zero, track
>>> the code flow there.  It means either intel_encoder is NULL or
>>> intel_dig_port->audio_connector is NULL.
>>
>> intel_dig_port->audio_connector is NULL!
>>
>> (when called during boot and during HDMI plugin)
>
> Interesting.  The relevant code flow should be like:
>
>   intel_audio_codec_enable()
>   -> acomp->audio_ops->pin_eld_notify()
> -> intel_pin_eld_notify()
>   -> check_presence_and_report()
> -> hdmi_present_sense()
> -> sync_eld_via_acomp()
>   -> snd_hdac_acomp_get_eld()
> -> i915_audio_component_get_eld()
>
> So, at first, check whether intel_dig_port in both
> intel_audio_codec_enable() and i915_audio_component_get_eld() points
> to the same object address.  The audio_connector must be set in
> intel_audio_codec_enable(), thus basically it must be non-NULL at
> i915_audio_component_get_eld(), too.
>

 intel_dig_port is *not* the same object in these 2 places. During
 plugin, see:

 [  146.934091] in intel_audio_codec_enable: intel_dig_port is
 8800a1f54000
 [  146.934121] in i915_audio_component_get_eld: intel_dig_port is
 880244f7d000

 sorry for the slow responses. I'll try to go back that direction unless
 again someone comes up with other suggestions.
>>>
>>> Thanks, this makes sense.  It implies that the digital port mapping is
>>> somehow wrong.  There are three places setting dig_port_map[], one in
>>> intel_ddi_init(), one in intel_dp_init() and another in
>>> intel_hdmi_init().  Try to check which function creates which object
>>> assigned to which port number, together with drm.debug=0x0e debug
>>> messages.
>>>
>> without using drm.debug=0x0e, but by printing the kmalloc'ed objects in
>> those 3 functions with ports, I found:
>>
>> 2 of them are running, only during boot:
>>
>> [2.322865] intel_hdmi_init: intel_dig_port is 880242564000  port 1
>> [2.322999] intel_dp_init: intel_dig_port is 880242f3  port 1
>>
>> is is correct for them to have both port 1? Any more ideas?
> 
> Adding intel-gfx ML to Cc.

yes thanks, maybe people there have noticed this too. I can't be the
only one.

> 
> Martin, is the machine SandyBridge or IvyBridge?

SandyBridge.

> 
> In anyway it's PCH_SPLIT and there can call both intel_hdmi_init() and 
> intel_dp_init() for the same port although both functions map
> intel_dig_port[].  The assumption of intel_dig_port[] reverse mapping
> is that there is only a single intel_dig_port assigned to a port, but
> this doesn't look correct...
> 
> 
> Takashi
> 

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

Re: [Intel-gfx] [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915

[Ville Syrjälä]

On Tue, Feb 23, 2016 at 05:57:40PM +0100, Takashi Iwai wrote:
> On Mon, 22 Feb 2016 22:37:28 +0100,
> Martin Kepplinger wrote:
> > 
> > Am 2016-02-22 um 20:10 schrieb Takashi Iwai:
> > > On Mon, 22 Feb 2016 19:58:18 +0100,
> > > Martin Kepplinger wrote:
> > >>
> > >> Am 2016-02-22 um 15:12 schrieb Takashi Iwai:
> > >>> On Mon, 22 Feb 2016 15:02:56 +0100,
> > >>> Martin Kepplinger wrote:
> > > And how about my questions in the previous mail?  Does
> > > i915_audio_component_get_eld() is called and returns 0?
> > > And is monitor_present set true or false?
> > 
> >  i915_audio_component_get_eld() returns 0 and monitor_present is 0.
> > >
> > > If i915_audio_component_get_eld() is called but returns zero, track
> > > the code flow there.  It means either intel_encoder is NULL or
> > > intel_dig_port->audio_connector is NULL.
> > 
> >  intel_dig_port->audio_connector is NULL!
> > 
> >  (when called during boot and during HDMI plugin)
> > >>>
> > >>> Interesting.  The relevant code flow should be like:
> > >>>
> > >>>   intel_audio_codec_enable()
> > >>>   -> acomp->audio_ops->pin_eld_notify()
> > >>> -> intel_pin_eld_notify()
> > >>>   -> check_presence_and_report()
> > >>> -> hdmi_present_sense()
> > >>>   -> sync_eld_via_acomp()
> > >>> -> snd_hdac_acomp_get_eld()
> > >>>   -> i915_audio_component_get_eld()
> > >>>
> > >>> So, at first, check whether intel_dig_port in both
> > >>> intel_audio_codec_enable() and i915_audio_component_get_eld() points
> > >>> to the same object address.  The audio_connector must be set in
> > >>> intel_audio_codec_enable(), thus basically it must be non-NULL at
> > >>> i915_audio_component_get_eld(), too.
> > >>>
> > >>
> > >> intel_dig_port is *not* the same object in these 2 places. During
> > >> plugin, see:
> > >>
> > >> [  146.934091] in intel_audio_codec_enable: intel_dig_port is
> > >> 8800a1f54000
> > >> [  146.934121] in i915_audio_component_get_eld: intel_dig_port is
> > >> 880244f7d000
> > >>
> > >> sorry for the slow responses. I'll try to go back that direction unless
> > >> again someone comes up with other suggestions.
> > > 
> > > Thanks, this makes sense.  It implies that the digital port mapping is
> > > somehow wrong.  There are three places setting dig_port_map[], one in
> > > intel_ddi_init(), one in intel_dp_init() and another in
> > > intel_hdmi_init().  Try to check which function creates which object
> > > assigned to which port number, together with drm.debug=0x0e debug
> > > messages.
> > > 
> > without using drm.debug=0x0e, but by printing the kmalloc'ed objects in
> > those 3 functions with ports, I found:
> > 
> > 2 of them are running, only during boot:
> > 
> > [2.322865] intel_hdmi_init: intel_dig_port is 880242564000  port 1
> > [2.322999] intel_dp_init: intel_dig_port is 880242f3  port 1
> > 
> > is is correct for them to have both port 1? Any more ideas?
> 
> Adding intel-gfx ML to Cc.
> 
> Martin, is the machine SandyBridge or IvyBridge?
> 
> In anyway it's PCH_SPLIT and there can call both intel_hdmi_init() and 
> intel_dp_init() for the same port although both functions map
> intel_dig_port[].  The assumption of intel_dig_port[] reverse mapping
> is that there is only a single intel_dig_port assigned to a port, but
> this doesn't look correct...

On pre-HSW there can indeed be two encoders for the same port.
And I'm planning to change HSW+ to follow that model as well,
but I've been busy with other stuff to finish off that work [1]

[1] https://lists.freedesktop.org/archives/intel-gfx/2015-December/082384.html

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

Re: [Intel-gfx] [BUG] [REGRESSION] [BISECTED] -rc1 breaks audio over HDMI for i915

[Takashi Iwai]

On Mon, 22 Feb 2016 22:37:28 +0100,
Martin Kepplinger wrote:
> 
> Am 2016-02-22 um 20:10 schrieb Takashi Iwai:
> > On Mon, 22 Feb 2016 19:58:18 +0100,
> > Martin Kepplinger wrote:
> >>
> >> Am 2016-02-22 um 15:12 schrieb Takashi Iwai:
> >>> On Mon, 22 Feb 2016 15:02:56 +0100,
> >>> Martin Kepplinger wrote:
> > And how about my questions in the previous mail?  Does
> > i915_audio_component_get_eld() is called and returns 0?
> > And is monitor_present set true or false?
> 
>  i915_audio_component_get_eld() returns 0 and monitor_present is 0.
> >
> > If i915_audio_component_get_eld() is called but returns zero, track
> > the code flow there.  It means either intel_encoder is NULL or
> > intel_dig_port->audio_connector is NULL.
> 
>  intel_dig_port->audio_connector is NULL!
> 
>  (when called during boot and during HDMI plugin)
> >>>
> >>> Interesting.  The relevant code flow should be like:
> >>>
> >>>   intel_audio_codec_enable()
> >>>   -> acomp->audio_ops->pin_eld_notify()
> >>> -> intel_pin_eld_notify()
> >>>   -> check_presence_and_report()
> >>> -> hdmi_present_sense()
> >>> -> sync_eld_via_acomp()
> >>>   -> snd_hdac_acomp_get_eld()
> >>> -> i915_audio_component_get_eld()
> >>>
> >>> So, at first, check whether intel_dig_port in both
> >>> intel_audio_codec_enable() and i915_audio_component_get_eld() points
> >>> to the same object address.  The audio_connector must be set in
> >>> intel_audio_codec_enable(), thus basically it must be non-NULL at
> >>> i915_audio_component_get_eld(), too.
> >>>
> >>
> >> intel_dig_port is *not* the same object in these 2 places. During
> >> plugin, see:
> >>
> >> [  146.934091] in intel_audio_codec_enable: intel_dig_port is
> >> 8800a1f54000
> >> [  146.934121] in i915_audio_component_get_eld: intel_dig_port is
> >> 880244f7d000
> >>
> >> sorry for the slow responses. I'll try to go back that direction unless
> >> again someone comes up with other suggestions.
> > 
> > Thanks, this makes sense.  It implies that the digital port mapping is
> > somehow wrong.  There are three places setting dig_port_map[], one in
> > intel_ddi_init(), one in intel_dp_init() and another in
> > intel_hdmi_init().  Try to check which function creates which object
> > assigned to which port number, together with drm.debug=0x0e debug
> > messages.
> > 
> without using drm.debug=0x0e, but by printing the kmalloc'ed objects in
> those 3 functions with ports, I found:
> 
> 2 of them are running, only during boot:
> 
> [2.322865] intel_hdmi_init: intel_dig_port is 880242564000  port 1
> [2.322999] intel_dp_init: intel_dig_port is 880242f3  port 1
> 
> is is correct for them to have both port 1? Any more ideas?

Adding intel-gfx ML to Cc.

Martin, is the machine SandyBridge or IvyBridge?

In anyway it's PCH_SPLIT and there can call both intel_hdmi_init() and 
intel_dp_init() for the same port although both functions map
intel_dig_port[].  The assumption of intel_dig_port[] reverse mapping
is that there is only a single intel_dig_port assigned to a port, but
this doesn't look correct...


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

Re: [Intel-gfx] [RFC] drm/i915: Check if we hold a wakeref during ioread32/iowrite32

[Chris Wilson]

On Tue, Feb 23, 2016 at 05:09:29PM +0200, Imre Deak wrote:
> On ti, 2016-02-23 at 14:55 +, Chris Wilson wrote:
> > On Tue, Feb 23, 2016 at 04:47:17PM +0200, Imre Deak wrote:
> > > The device needs to be in D0 state whenever we call these
> > > functions, so
> > > add the corresponding assert checks.
> > 
> > No. In quite a few of those cases we are calling iowrite to non-
> > device
> > memory, even normal pages.
> 
> Hm right didn't think about that. I guess the only case we care about
> then are accesses through the GTT.
> 
> > How's the separation of struct_mutex from rpm going so that we can
> > forgo
> > adding assertions and use explicit power management instead?
> 
> It's planned to be done, but no one is working on that yet. This is
> something we could still have regardless, similarly to other helpers
> accessing the device.

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 31b600d31158..b8687b6a6acb 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1430,24 +1430,6 @@ static int intel_runtime_suspend(struct device *device)
 
DRM_DEBUG_KMS("Suspending device\n");
 
-   /*
-* We could deadlock here in case another thread holding struct_mutex
-* calls RPM suspend concurrently, since the RPM suspend will wait
-* first for this RPM suspend to finish. In this case the concurrent
-* RPM resume will be followed by its RPM suspend counterpart. Still
-* for consistency return -EAGAIN, which will reschedule this suspend.
-*/
-   if (!mutex_trylock(>struct_mutex)) {
-   DRM_DEBUG_KMS("device lock contention, deffering suspend\n");
-   /*
-* Bump the expiration timestamp, otherwise the suspend won't
-* be rescheduled.
-*/
-   pm_runtime_mark_last_busy(device);
-
-   return -EAGAIN;
-   }
-
disable_rpm_wakeref_asserts(dev_priv);
 
/*
@@ -1455,7 +1437,6 @@ static int intel_runtime_suspend(struct device *device)
 * an RPM reference.
 */
i915_gem_release_all_mmaps(dev_priv);
-   mutex_unlock(>struct_mutex);
 
intel_guc_suspend(dev);
 
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 79706621e6e4..4f6127466822 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1670,9 +1670,13 @@ i915_gem_release_mmap(struct drm_i915_gem_object *obj)
/* Serialisation between user GTT access and our code depends upon
 * revoking the CPU's PTE whilst the mutex is held. The next user
 * pagefault then has to wait until we release the mutex.
+*
+* Note that RPM complicates somewhat by adding an additional
+* requirement that operations to the GGTT be made holding the RPM
+* wakeref. This in turns allow us to release the mmap from within
+* the RPM suspend code ignoring the struct_mutex serialisation in
+* lieu of the RPM barriers.
 */
-   lockdep_assert_held(>base.dev->struct_mutex);
-
if (!obj->fault_mappable)
return;
 
@@ -1685,11 +1689,21 @@ i915_gem_release_mmap(struct drm_i915_gem_object *obj)
obj->fault_mappable = false;
 }
 
+static void assert_rpm_release_all_mmaps(struct drm_i915_private *dev_priv)
+{
+   assert_rpm_wakelock_held(dev_priv);
+}
+
 void
 i915_gem_release_all_mmaps(struct drm_i915_private *dev_priv)
 {
struct drm_i915_gem_object *obj;
 
+   /* This should only be called by RPM as we require the bound_list
+* to be protected by the RPM barriers and not struct_mutex.
+* We check that we are holding the wakeref whenever we manipulate
+* the dev_priv->mm.bound_list (via assert_rpm_release_all_mmaps).
+*/
list_for_each_entry(obj, _priv->mm.bound_list, global_list)
i915_gem_release_mmap(obj);
 }
@@ -2224,9 +2238,11 @@ i915_gem_object_retire__read(struct i915_gem_active 
*active,
 * so that we don't steal from recently used but inactive objects
 * (unless we are forced to ofc!)
 */
-   if (obj->bind_count)
+   if (obj->bind_count) {
+   assert_rpm_release_all_mmaps(request->i915);
list_move_tail(>global_list,
   >i915->mm.bound_list);
+   }
 
if (i915_gem_object_has_active_reference(obj)) {
i915_gem_object_unset_active_reference(obj);
@@ -2751,9 +2767,11 @@ int i915_vma_unbind(struct i915_vma *vma)
 
/* Since the unbound list is global, only move to that list if
 * no more VMAs exist. */
-   if (--obj->bind_count == 0)
+   if (--obj->bind_count == 0) {
+   assert_rpm_release_all_mmaps(to_i915(obj->base.dev));
list_move_tail(>global_list,
   _i915(obj->base.dev)->mm.unbound_list);
+ 

[Intel-gfx] [PATCH 4/4] drm/i915: Determine DP++ type 1 DVI adaptor presence based on VBT

[ville . syrjala]

From: Ville Syrjälä 

DP dual mode type 1 DVI adaptors aren't required to implement any
registers, so it's a bit hard to detect them. The best way would
be to check the state of the CONFIG1 pin, but we have no way to
do that. So as a last resort, check the VBT to see if the HDMI
port is in fact a dual mode capable DP port.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_bios.h |  3 +++
 drivers/gpu/drm/i915/intel_dp.c   | 28 
 drivers/gpu/drm/i915/intel_drv.h  |  1 +
 drivers/gpu/drm/i915/intel_hdmi.c | 23 +--
 4 files changed, 53 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_bios.h 
b/drivers/gpu/drm/i915/intel_bios.h
index 350d4e0f75a4..50d1659efe47 100644
--- a/drivers/gpu/drm/i915/intel_bios.h
+++ b/drivers/gpu/drm/i915/intel_bios.h
@@ -730,6 +730,7 @@ struct bdb_psr {
 #define DEVICE_TYPE_INT_TV 0x1009
 #define DEVICE_TYPE_HDMI   0x60D2
 #define DEVICE_TYPE_DP 0x68C6
+#define DEVICE_TYPE_DP_DUAL_MODE   0x60D6
 #define DEVICE_TYPE_eDP0x78C6
 
 #define  DEVICE_TYPE_CLASS_EXTENSION   (1 << 15)
@@ -764,6 +765,8 @@ struct bdb_psr {
 DEVICE_TYPE_DISPLAYPORT_OUTPUT | \
 DEVICE_TYPE_ANALOG_OUTPUT)
 
+#define DEVICE_TYPE_DP_DUAL_MODE_BITS ~DEVICE_TYPE_NOT_HDMI_OUTPUT
+
 /* define the DVO port for HDMI output type */
 #defineDVO_B   1
 #defineDVO_C   2
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index cbc06596659a..f3edacf517ac 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5104,6 +5104,34 @@ bool intel_dp_is_edp(struct drm_device *dev, enum port 
port)
return false;
 }
 
+bool intel_dp_is_dual_mode(struct drm_i915_private *dev_priv, enum port port)
+{
+   const union child_device_config *p_child;
+   int i;
+   static const short port_mapping[] = {
+   [PORT_B] = DVO_PORT_DPB,
+   [PORT_C] = DVO_PORT_DPC,
+   [PORT_D] = DVO_PORT_DPD,
+   [PORT_E] = DVO_PORT_DPE,
+   };
+
+   if (port == PORT_A || port >= ARRAY_SIZE(port_mapping))
+   return false;
+
+   if (!dev_priv->vbt.child_dev_num)
+   return false;
+
+   for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
+   p_child = _priv->vbt.child_dev[i];
+
+   if (p_child->common.dvo_port == port_mapping[port] &&
+   (p_child->common.device_type & 
DEVICE_TYPE_DP_DUAL_MODE_BITS) ==
+   (DEVICE_TYPE_DP_DUAL_MODE & DEVICE_TYPE_DP_DUAL_MODE_BITS))
+   return true;
+   }
+   return false;
+}
+
 void
 intel_dp_add_properties(struct intel_dp *intel_dp, struct drm_connector 
*connector)
 {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 3ca29a181e64..c7d1ea4dbe42 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1248,6 +1248,7 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, u8 *crc);
 bool intel_dp_compute_config(struct intel_encoder *encoder,
 struct intel_crtc_state *pipe_config);
 bool intel_dp_is_edp(struct drm_device *dev, enum port port);
+bool intel_dp_is_dual_mode(struct drm_i915_private *dev_priv, enum port port);
 enum irqreturn intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port,
  bool long_hpd);
 void intel_edp_backlight_on(struct intel_dp *intel_dp);
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 660a65f48fd8..1476f3afb7e2 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1390,14 +1390,33 @@ intel_hdmi_unset_edid(struct drm_connector *connector)
 }
 
 static void
-intel_hdmi_dp_dual_mode_detect(struct drm_connector *connector)
+intel_hdmi_dp_dual_mode_detect(struct drm_connector *connector, bool has_edid)
 {
struct drm_i915_private *dev_priv = to_i915(connector->dev);
struct intel_hdmi *hdmi = intel_attached_hdmi(connector);
+   enum port port = hdmi_to_dig_port(hdmi)->port;
struct i2c_adapter *adapter =
intel_gmbus_get_adapter(dev_priv, hdmi->ddc_bus);
enum drm_dp_dual_mode_type type = drm_dp_dual_mode_detect(adapter);
 
+   /*
+* Type 1 DVI adaptors are not required to implement any
+* registers, so we can't always detect their presence.
+* Ideally we should be able to check the state of the
+* CONFIG1 pin, but no such luck on our hardware.
+*
+* The only method left to us is to check the VBT to see
+* if the port is a dual mode capable DP port. But let's
+* only do that when we sucesfully read the EDID, to avoid
+* confusing log messages about DP dual mode 

[Intel-gfx] [PATCH 1/4] drm: Add helper for DP++ adaptors

[ville . syrjala]

From: Ville Syrjälä 

Add a helper which aids in he identification of DP dual mode (aka. DP++)
adaptors. There are several types of adaptors specified:
type 1 DVI, type 1 HDMI, type 2 DVI, type 2 HDMI

Type 1 adaptors have a max TMDS clock limit of 165MHz, type 2 adaptors
may go as high as 300MHz and they provide a register informing the
source device what the actual limit is. Supposedly also type 1 adaptors
may optionally implement this register. This TMDS clock limit is the
main reason why we need to identify these adaptors.

Type 1 adaptors provide access to their internal registers and the sink
DDC bus through I2C. Type 2 adaptors provide this access both via I2C
and I2C-over-AUX. A type 2 source device may choose to implement either
or both of these methods. If a source device implements only the
I2C-over-AUX method, then the driver will obviously need specific
support for such adaptors since the port is driven like an HDMI port,
but DDC communication happes over the AUX channel.

This helper should be enough to identify the adaptor type (some
type 1 DVI adaptors may be a slight exception) and the maximum TMDS
clock limit. Another feature that may be available is control over
the TMDS output buffers on the adaptor, possibly allowing for some
power saving when the TMDS link is down.

Other user controllable features that may be available in the adaptors
are downstream i2c bus speed control when using i2c-over-aux, and
some control over the CEC pin. I chose not to provide any helper
functions for those since I have no use for them in i915 at this time.
The rest of the registers in the adaptor are mostly just information,
eg. IEEE OUI, hardware and firmware revision, etc.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/Makefile  |   2 +-
 drivers/gpu/drm/drm_dp_dual_mode_helper.c | 328 ++
 include/drm/drm_dp_dual_mode_helper.h |  80 
 3 files changed, 409 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/drm_dp_dual_mode_helper.c
 create mode 100644 include/drm/drm_dp_dual_mode_helper.h

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 6eb94fc561dc..8ef50f36 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -23,7 +23,7 @@ drm-$(CONFIG_AGP) += drm_agpsupport.o
 
 drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
-   drm_kms_helper_common.o
+   drm_kms_helper_common.o drm_dp_dual_mode_helper.o
 
 drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
 drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
diff --git a/drivers/gpu/drm/drm_dp_dual_mode_helper.c 
b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
new file mode 100644
index ..bfe511c09568
--- /dev/null
+++ b/drivers/gpu/drm/drm_dp_dual_mode_helper.c
@@ -0,0 +1,328 @@
+/*
+ * 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 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 COPYRIGHT HOLDER(S) OR AUTHOR(S) 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 
+#include 
+#include 
+#include 
+
+/**
+ * DOC: DP dual mode (aka. DP++) adaptor helpers
+ *
+ * Helper functions to deal with DP dual mode adaptors.
+ *
+ * Type 1:
+ * Adaptor registers (if any) and the sink DDC bus may be accessed via I2C.
+ *
+ * Type 2:
+ * Adaptor registers and sink DDC bus can be accessed either via I2C or
+ * I2C-over-AUX. Source devices may choose to implement either one or
+ * both of these access methods.
+ */
+
+#define DP_DUAL_MODE_SLAVE_ADDRESS 0x40
+
+/**
+ * drm_dp_dual_mode_read - Read from the DP dual mode adaptor register(s)
+ * adapter: I2C adapter for the DDC bus
+ * offset: register offset
+ * buffer: buffer for return data
+ * size: sizo of the buffer
+ *
+ * Reads @size bytes from the DP dual mode adaptor registers
+ * starting at 

[Intel-gfx] [PATCH 3/4] drm/i915: Enable/disable TMDS output buffers in DP++ adaptor as needed

[ville . syrjala]

From: Ville Syrjälä 

To save a bit of power, let's try to turn off the TMDS output buffers
in DP++ adaptors when we're not driving the port.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_drv.h  |  1 +
 drivers/gpu/drm/i915/intel_hdmi.c | 27 +--
 2 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 944eacbfb6a9..3ca29a181e64 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -706,6 +706,7 @@ struct intel_hdmi {
int ddc_bus;
struct {
int max_tmds_clock;
+   bool tmds_output_control;
} dp_dual_mode;
bool limited_color_range;
bool color_range_auto;
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 1e8cfdb18dc7..660a65f48fd8 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -846,6 +846,13 @@ static void intel_hdmi_prepare(struct intel_encoder 
*encoder)
const struct drm_display_mode *adjusted_mode = 
>config->base.adjusted_mode;
u32 hdmi_val;
 
+   if (intel_hdmi->dp_dual_mode.tmds_output_control) {
+   struct i2c_adapter *adapter =
+   intel_gmbus_get_adapter(dev_priv, intel_hdmi->ddc_bus);
+
+   drm_dp_dual_mode_set_tmds_output(adapter, true);
+   }
+
hdmi_val = SDVO_ENCODING_HDMI;
if (!HAS_PCH_SPLIT(dev) && crtc->config->limited_color_range)
hdmi_val |= HDMI_COLOR_RANGE_16_235;
@@ -1144,6 +1151,13 @@ static void intel_disable_hdmi(struct intel_encoder 
*encoder)
}
 
intel_hdmi->set_infoframes(>base, false, NULL);
+
+   if (intel_hdmi->dp_dual_mode.tmds_output_control) {
+   struct i2c_adapter *adapter =
+   intel_gmbus_get_adapter(dev_priv, intel_hdmi->ddc_bus);
+
+   drm_dp_dual_mode_set_tmds_output(adapter, false);
+   }
 }
 
 static void g4x_disable_hdmi(struct intel_encoder *encoder)
@@ -1369,6 +1383,7 @@ intel_hdmi_unset_edid(struct drm_connector *connector)
intel_hdmi->rgb_quant_range_selectable = false;
 
intel_hdmi->dp_dual_mode.max_tmds_clock = 0;
+   intel_hdmi->dp_dual_mode.tmds_output_control = false;
 
kfree(to_intel_connector(connector)->detect_edid);
to_intel_connector(connector)->detect_edid = NULL;
@@ -1392,15 +1407,23 @@ intel_hdmi_dp_dual_mode_detect(struct drm_connector 
*connector)
 */
if (type == DRM_DP_DUAL_MODE_TYPE2_DVI ||
type == DRM_DP_DUAL_MODE_TYPE2_HDMI) {
+   bool tmds_enabled;
+
hdmi->dp_dual_mode.max_tmds_clock =
drm_dp_dual_mode_max_tmds_clock(adapter);
+
+   hdmi->dp_dual_mode.tmds_output_control =
+   drm_dp_dual_mode_get_tmds_output(adapter, 
_enabled) == 0 &&
+   drm_dp_dual_mode_set_tmds_output(adapter, tmds_enabled) 
== 0;
} else {
hdmi->dp_dual_mode.max_tmds_clock = 165000;
+   hdmi->dp_dual_mode.tmds_output_control = false;
}
 
-   DRM_DEBUG_KMS("DP dual mode adaptor (%s) detected (max TMDS clock: %d 
kHz)\n",
+   DRM_DEBUG_KMS("DP dual mode adaptor (%s) detected (max TMDS clock: %d 
kHz, TMDS OE# control: %s)\n",
  drm_dp_get_dual_mode_type_name(type),
- hdmi->dp_dual_mode.max_tmds_clock);
+ hdmi->dp_dual_mode.max_tmds_clock,
+ yesno(hdmi->dp_dual_mode.tmds_output_control));
 }
 
 static bool
-- 
2.4.10

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

[Intel-gfx] [PATCH 2/4] drm/i915: Respect DP++ adaptor TMDS clock limit

[ville . syrjala]

From: Ville Syrjälä 

Try to detect the max TMDS clock limit for the DP++ adaptor (if any)
and take it into account when checking the port clock.

Note that as with the sink (HDMI vs. DVI) TMDS clock limit we'll ignore
the adaptor TMDS clock limit in the modeset path, in case users are
already "overclocking" their TMDS links. One subtle change here is that
we'll have to respect the adaptor TMDS clock limit when we decide whether
to do 12bpc or 8bpc, otherwise we might end up picking 12bpc and
accidentally driving the TMDS link out of spec even when the user chose
a mode that fits wihting the limits at 8bpc. This means you can't
"overclock" your DP++ dongle at 12bpc anymore, but you can continue to
do so at 8bpc.

Note that for simplicity we'll use the I2C access method for all dual
mode adaptors including type 2. Otherwise we'd have to start mixing
DP AUX and HDMI together. In the future we may need to do that if we
come across any board designs that don't hook up the DDC pins to the
DP++ connectors. Such boards would obviously only work with type 2
dual mode adaptors, and not type 1.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_drv.h  |  3 ++
 drivers/gpu/drm/i915/intel_hdmi.c | 65 ++-
 2 files changed, 60 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 4852049c9ab3..944eacbfb6a9 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -704,6 +704,9 @@ struct cxsr_latency {
 struct intel_hdmi {
i915_reg_t hdmi_reg;
int ddc_bus;
+   struct {
+   int max_tmds_clock;
+   } dp_dual_mode;
bool limited_color_range;
bool color_range_auto;
bool has_hdmi_sink;
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 80b44c054087..1e8cfdb18dc7 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "intel_drv.h"
 #include 
 #include "i915_drv.h"
@@ -1168,27 +1169,42 @@ static void pch_post_disable_hdmi(struct intel_encoder 
*encoder)
intel_disable_hdmi(encoder);
 }
 
-static int hdmi_port_clock_limit(struct intel_hdmi *hdmi, bool 
respect_dvi_limit)
+static int intel_hdmi_source_max_tmds_clock(struct drm_i915_private *dev_priv)
 {
-   struct drm_device *dev = intel_hdmi_to_dev(hdmi);
-
-   if ((respect_dvi_limit && !hdmi->has_hdmi_sink) || IS_G4X(dev))
+   if (IS_G4X(dev_priv))
return 165000;
-   else if (IS_HASWELL(dev) || INTEL_INFO(dev)->gen >= 8)
+   else if (IS_HASWELL(dev_priv) || INTEL_INFO(dev_priv)->gen >= 8)
return 30;
else
return 225000;
 }
 
+static int hdmi_port_clock_limit(struct intel_hdmi *hdmi,
+bool respect_downstream_limits)
+{
+   struct drm_device *dev = intel_hdmi_to_dev(hdmi);
+   int max_tmds_clock = intel_hdmi_source_max_tmds_clock(to_i915(dev));
+
+   if (respect_downstream_limits) {
+   if (hdmi->dp_dual_mode.max_tmds_clock)
+   max_tmds_clock = min(max_tmds_clock,
+hdmi->dp_dual_mode.max_tmds_clock);
+   if (!hdmi->has_hdmi_sink)
+   max_tmds_clock = min(max_tmds_clock, 165000);
+   }
+
+   return max_tmds_clock;
+}
+
 static enum drm_mode_status
 hdmi_port_clock_valid(struct intel_hdmi *hdmi,
- int clock, bool respect_dvi_limit)
+ int clock, bool respect_downstream_limits)
 {
struct drm_device *dev = intel_hdmi_to_dev(hdmi);
 
if (clock < 25000)
return MODE_CLOCK_LOW;
-   if (clock > hdmi_port_clock_limit(hdmi, respect_dvi_limit))
+   if (clock > hdmi_port_clock_limit(hdmi, respect_downstream_limits))
return MODE_CLOCK_HIGH;
 
/* BXT DPLL can't generate 223-240 MHz */
@@ -1312,7 +1328,7 @@ bool intel_hdmi_compute_config(struct intel_encoder 
*encoder,
 * within limits.
 */
if (pipe_config->pipe_bpp > 8*3 && pipe_config->has_hdmi_sink &&
-   hdmi_port_clock_valid(intel_hdmi, clock_12bpc, false) == MODE_OK &&
+   hdmi_port_clock_valid(intel_hdmi, clock_12bpc, true) == MODE_OK &&
hdmi_12bpc_possible(pipe_config)) {
DRM_DEBUG_KMS("picking bpc to 12 for HDMI output\n");
desired_bpp = 12*3;
@@ -1352,10 +1368,41 @@ intel_hdmi_unset_edid(struct drm_connector *connector)
intel_hdmi->has_audio = false;
intel_hdmi->rgb_quant_range_selectable = false;
 
+   intel_hdmi->dp_dual_mode.max_tmds_clock = 0;
+
kfree(to_intel_connector(connector)->detect_edid);
to_intel_connector(connector)->detect_edid = NULL;
 }
 
+static void

Re: [Intel-gfx] [RFC i-g-t] tests/drv_hangman: test for acthd increasing through invalid VM space

[Daniele Ceraolo Spurio]

On 18/02/16 21:10, Chris Wilson wrote:

On Thu, Feb 18, 2016 at 05:34:50PM +, daniele.ceraolospu...@intel.com wrote:

+static void ppgtt_walking(void)
+{
+   memset(, 0, sizeof(execbuf));
+   execbuf.buffers_ptr = (uintptr_t)_exec;
+   execbuf.buffer_count = 1;
+   execbuf.batch_len = 8;
+
+   gem_execbuf(fd, );
+
+   while (gem_bo_busy(fd, handle) && timeout > 0) {
+   igt_debug("decreasing timeout to %u\n", --timeout);
+   sleep(1);
+   }

See gem_wait()
-Chris


I couldn't find any gem_wait() function or any other wrapper for the 
i915_gem_wait ioctl in ioctl_wrappers.c (except for gem_sync). There is 
a gem_bo_wait_timeout wrapper in gem_wait.c that could probably be moved 
to ioctl_wrappers, or I could just add the ioctl call here. What option 
would work better for you?


Thanks,
Daniele

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Updating the CPU_TRANSCODER for BXT DSI

[Patchwork]

== Series Details ==

Series: drm/i915: Updating the CPU_TRANSCODER for BXT DSI
URL   : https://patchwork.freedesktop.org/series/3730/
State : failure

== Summary ==

Series 3730v1 drm/i915: Updating the CPU_TRANSCODER for BXT DSI
2016-02-23T15:07:40.910533 
http://patchwork.freedesktop.org/api/1.0/series/3730/revisions/1/mbox/
Applying: drm/i915: Updating the CPU_TRANSCODER for BXT DSI
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 drm/i915: Updating the CPU_TRANSCODER for BXT DSI

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Check if we hold a wakeref during ioread32/iowrite32

[Patchwork]

== Series Details ==

Series: drm/i915: Check if we hold a wakeref during ioread32/iowrite32
URL   : https://patchwork.freedesktop.org/series/3728/
State : failure

== Summary ==

Series 3728v1 drm/i915: Check if we hold a wakeref during ioread32/iowrite32
http://patchwork.freedesktop.org/api/1.0/series/3728/revisions/1/mbox/

Test gem_cs_prefetch:
Subgroup basic-default:
incomplete -> PASS   (ilk-hp8440p)
Test gem_sync:
Subgroup basic-blt:
pass   -> INCOMPLETE (ivb-t430s)
Test kms_force_connector_basic:
Subgroup force-edid:
skip   -> PASS   (snb-x220t)
pass   -> SKIP   (ivb-t430s)
Subgroup force-load-detect:
dmesg-fail -> FAIL   (snb-x220t)
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-c:
pass   -> TIMEOUT(ivb-t430s)
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (skl-i5k-2) UNSTABLE
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (skl-i5k-2) UNSTABLE
Test pm_rpm:
Subgroup basic-rte:
dmesg-warn -> PASS   (byt-nuc) UNSTABLE

bdw-nuci7total:165  pass:154  dwarn:0   dfail:0   fail:0   skip:11 
bdw-ultratotal:168  pass:154  dwarn:0   dfail:0   fail:0   skip:14 
bsw-nuc-2total:168  pass:137  dwarn:0   dfail:0   fail:1   skip:30 
byt-nuc  total:168  pass:143  dwarn:0   dfail:0   fail:0   skip:25 
hsw-gt2  total:168  pass:157  dwarn:0   dfail:1   fail:0   skip:10 
ilk-hp8440p  total:168  pass:118  dwarn:0   dfail:0   fail:1   skip:49 
ivb-t430stotal:63   pass:55   dwarn:0   dfail:0   fail:1   skip:5  
skl-i5k-2total:168  pass:151  dwarn:1   dfail:0   fail:0   skip:16 
snb-dellxps  total:168  pass:145  dwarn:0   dfail:1   fail:0   skip:22 
snb-x220ttotal:168  pass:145  dwarn:0   dfail:0   fail:2   skip:21 

Results at /archive/results/CI_IGT_test/Patchwork_1466/

08fc1b101049694778bff7559e1d05250d2e7072 drm-intel-nightly: 
2016y-02m-22d-17h-30m-27s UTC integration manifest
c99c6cfec524f93a828a8b366929054e9c94164d drm/i915: Check if we hold a wakeref 
during ioread32/iowrite32

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

[Intel-gfx] Intel Graphics for Linux (Release Date: 16 Feb, 2016)

[Sedat Dilek]

Hi,

what packages with versions is recent "Intel Graphics for Linux"
(2016-02-16) shipping?
Version "2015q4" [2] was giving some detailed informations, but recent
version does not.
Its release-notes are pointing to a installer [3].

BTW, when will there be a new intel-ddx v2.99.918?

Thanks in advance.

Regards,
- Sedat -

[1] https://01.org/linuxgraphics
[2] https://01.org/linuxgraphics/downloads/2015q4-intel-graphics-stack-release
[3] https://01.org/linuxgraphics/downloads/intel-graphics-installer-linux-1.4.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [IGT PATCH] tests/kms_setmode: Add tests when not stealing encoders on same crtc.

[Maarten Lankhorst]

Excercise connector stealing harder. There is a border case in atomic currently 
where
encoder stealing is not prevented on the same crtc when the encoder is not 
reassigned.

The following testcase excercises that path and causes a OOPS on my system with 
nightly.

Signed-off-by: Maarten Lankhorst 
---
The patches from drm/atomic: Fix encoder stealing fixes it, but I'll resend 
those soon,
I came up with another approach that's cleaner.

diff --git a/tests/kms_setmode.c b/tests/kms_setmode.c
index 531ce8391fa7..6afe00c126fe 100644
--- a/tests/kms_setmode.c
+++ b/tests/kms_setmode.c
@@ -70,6 +70,7 @@ enum test_flags {
TEST_CLONE  = 0x02,
TEST_SINGLE_CRTC_CLONE  = 0x04,
TEST_EXCLUSIVE_CRTC_CLONE   = 0x08,
+   TEST_STEALING   = 0x10,
 };
 
 struct test_config {
@@ -380,6 +381,34 @@ static uint32_t *get_connector_ids(struct crtc_config 
*crtc)
return ids;
 }
 
+static int test_stealing(int drm_fd, const struct crtc_config *crtc, uint32_t 
*ids)
+{
+   int i, ret = 0;
+
+   if (!crtc->connector_count)
+   return drmModeSetCrtc(drm_fd, crtc->crtc_id,
+crtc->fb_info.fb_id, 0, 0,
+ids, crtc->connector_count, >mode);
+
+   for (i = 0; i < crtc->connector_count; ++i) {
+   ret = drmModeSetCrtc(drm_fd, crtc->crtc_id,
+crtc->fb_info.fb_id, 0, 0,
+[i], 1, >mode);
+
+   igt_assert_eq(ret, 0);
+
+   ret = drmModeSetCrtc(drm_fd, crtc->crtc_id,
+crtc->fb_info.fb_id, 0, 0,
+ids, crtc->connector_count, >mode);
+
+   /* This should fail with -EINVAL */
+   if (!ret)
+   return 0;
+   }
+
+   return ret;
+}
+
 static void test_crtc_config(const struct test_config *tconf,
 struct crtc_config *crtcs, int crtc_count)
 {
@@ -422,9 +451,13 @@ static void test_crtc_config(const struct test_config 
*tconf,
paint_fb(>fb_info, tconf->name, crtc_strs, crtc_count, i);
 
ids = get_connector_ids(crtc);
-   ret = drmModeSetCrtc(drm_fd, crtc->crtc_id,
-crtc->fb_info.fb_id, 0, 0, ids,
-crtc->connector_count, >mode);
+   if (tconf->flags & TEST_STEALING)
+   ret = test_stealing(drm_fd, crtc, ids);
+   else
+   ret = drmModeSetCrtc(drm_fd, crtc->crtc_id,
+crtc->fb_info.fb_id, 0, 0, ids,
+crtc->connector_count, 
>mode);
+
free(ids);
 
if (ret < 0) {
@@ -623,6 +656,9 @@ static void test_combinations(const struct test_config 
*tconf,
struct connector_config *cconfs;
int i;
 
+   if (connector_count > 2 && (tconf->flags & TEST_STEALING))
+   return;
+
get_combinations(tconf->resources->count_connectors, connector_count,
 false, _combs);
get_combinations(tconf->resources->count_crtcs, connector_count,
@@ -700,6 +736,8 @@ int main(int argc, char **argv)
"invalid-clone-exclusive-crtc" },
{ TEST_CLONE | TEST_EXCLUSIVE_CRTC_CLONE,
"clone-exclusive-crtc" },
+   { TEST_INVALID | TEST_CLONE | TEST_SINGLE_CRTC_CLONE | 
TEST_STEALING,
+   "invalid-clone-single-crtc-stealing" }
};
const char *help_str =
   "  -d\t\tDon't run any test, only print what would be done. 
(still needs DRM access)\n"

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for Pipe level color management (rev7)

[Patchwork]

== Series Details ==

Series: Pipe level color management (rev7)
URL   : https://patchwork.freedesktop.org/series/2720/
State : failure

== Summary ==

Series 2720v7 Pipe level color management
http://patchwork.freedesktop.org/api/1.0/series/2720/revisions/7/mbox/

Test gem_cs_prefetch:
Subgroup basic-default:
incomplete -> PASS   (ilk-hp8440p)
Test kms_flip:
Subgroup basic-flip-vs-modeset:
pass   -> DMESG-WARN (ilk-hp8440p) UNSTABLE
Test kms_force_connector_basic:
Subgroup force-edid:
skip   -> PASS   (snb-x220t)
pass   -> SKIP   (ivb-t430s)
Subgroup force-load-detect:
dmesg-fail -> FAIL   (snb-x220t)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (skl-i5k-2) UNSTABLE
Subgroup suspend-read-crc-pipe-c:
pass   -> DMESG-WARN (skl-i5k-2) UNSTABLE
pass   -> DMESG-WARN (bsw-nuc-2)
pass   -> INCOMPLETE (hsw-gt2)
Test pm_rpm:
Subgroup basic-rte:
pass   -> DMESG-WARN (bsw-nuc-2)
dmesg-warn -> PASS   (byt-nuc) UNSTABLE

bdw-nuci7total:165  pass:154  dwarn:0   dfail:0   fail:0   skip:11 
bdw-ultratotal:168  pass:154  dwarn:0   dfail:0   fail:0   skip:14 
bsw-nuc-2total:168  pass:135  dwarn:2   dfail:0   fail:1   skip:30 
byt-nuc  total:168  pass:143  dwarn:0   dfail:0   fail:0   skip:25 
hsw-gt2  total:94   pass:88   dwarn:0   dfail:0   fail:0   skip:5  
ilk-hp8440p  total:168  pass:117  dwarn:1   dfail:0   fail:1   skip:49 
ivb-t430stotal:168  pass:152  dwarn:0   dfail:0   fail:1   skip:15 
skl-i5k-2total:168  pass:151  dwarn:1   dfail:0   fail:0   skip:16 
snb-dellxps  total:168  pass:145  dwarn:0   dfail:1   fail:0   skip:22 
snb-x220ttotal:168  pass:145  dwarn:0   dfail:0   fail:2   skip:21 

Results at /archive/results/CI_IGT_test/Patchwork_1465/

08fc1b101049694778bff7559e1d05250d2e7072 drm-intel-nightly: 
2016y-02m-22d-17h-30m-27s UTC integration manifest
90940b4f96a0e054427e822f75cf17a38ac8f899 drm/i915: Implement color management 
on chv
fcc35aaa6f5f2d2d451090afd82c491de12f90ab drm/i915: Implement color management 
on bdw/skl/bxt/kbl
ce8fa5620b1dfcfe8923705549d2bd29a4b43962 drm: introduce pipe color correction 
properties
5273b44508fce4868d66928abc9e6a47577ecbcd drm/i915: Do not read GAMMA_MODE 
register
c57b9921879e2980f9b8c06611a05c0c7ad2c7d3 drm/i915: Extract out gamma table and 
CSC to their own file

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

Re: [Intel-gfx] [RFC] drm/i915: Check if we hold a wakeref during ioread32/iowrite32

[Imre Deak]

On ti, 2016-02-23 at 14:55 +, Chris Wilson wrote:
> On Tue, Feb 23, 2016 at 04:47:17PM +0200, Imre Deak wrote:
> > The device needs to be in D0 state whenever we call these
> > functions, so
> > add the corresponding assert checks.
> 
> No. In quite a few of those cases we are calling iowrite to non-
> device
> memory, even normal pages.

Hm right didn't think about that. I guess the only case we care about
then are accesses through the GTT.

> How's the separation of struct_mutex from rpm going so that we can
> forgo
> adding assertions and use explicit power management instead?

It's planned to be done, but no one is working on that yet. This is
something we could still have regardless, similarly to other helpers
accessing the device.

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

[Intel-gfx] [PATCH] drm/i915: Updating the CPU_TRANSCODER for BXT DSI

[Ramalingam C]

In case of BXT DSI we are updating the CPU_TRANSCODER
with appropriate value. We are defining the POWER DOMAIN
bits for the MIPI transcoders.

V2: Adding the power domain bits and mapping them to the
corresponding Powerwell.

Signed-off-by: Ramalingam C 
Signed-off-by: Uma Shankar 
---
Previous review link: 
https://lists.freedesktop.org/archives/intel-gfx/2016-February/088304.html

 drivers/gpu/drm/i915/i915_drv.h |4 
 drivers/gpu/drm/i915/intel_display.c|5 +
 drivers/gpu/drm/i915/intel_runtime_pm.c |6 ++
 3 files changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6644c2e..7c177e9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -122,6 +122,8 @@ enum transcoder {
TRANSCODER_B,
TRANSCODER_C,
TRANSCODER_EDP,
+   TRANSCODER_MIPI_A,
+   TRANSCODER_MIPI_C,
I915_MAX_TRANSCODERS
 };
 #define transcoder_name(t) ((t) + 'A')
@@ -176,6 +178,8 @@ enum intel_display_power_domain {
POWER_DOMAIN_TRANSCODER_B,
POWER_DOMAIN_TRANSCODER_C,
POWER_DOMAIN_TRANSCODER_EDP,
+   POWER_DOMAIN_TRANSCODER_MIPI_A,
+   POWER_DOMAIN_TRANSCODER_MIPI_C,
POWER_DOMAIN_PORT_DDI_A_LANES,
POWER_DOMAIN_PORT_DDI_B_LANES,
POWER_DOMAIN_PORT_DDI_C_LANES,
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 86ed9fd..961a968 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7825,6 +7825,11 @@ static void intel_get_dsi_pipe_timings(struct intel_crtc 
*crtc,
enc_to_intel_dsi(>base);
pipe_config->pipe_bpp =
dsi_pixel_format_bpp(intel_dsi->pixel_format);
+
+   if (intel_dsi->ports & (1 << PORT_A))
+   pipe_config->cpu_transcoder = TRANSCODER_MIPI_A;
+   else
+   pipe_config->cpu_transcoder = TRANSCODER_MIPI_C;
}
}
 
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index a2e367c..1ed3f5e 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -89,6 +89,10 @@ intel_display_power_domain_str(enum 
intel_display_power_domain domain)
return "TRANSCODER_C";
case POWER_DOMAIN_TRANSCODER_EDP:
return "TRANSCODER_EDP";
+   case POWER_DOMAIN_TRANSCODER_MIPI_A:
+   return "TRANSCODER_MIPI_A";
+   case POWER_DOMAIN_TRANSCODER_MIPI_C:
+   return "TRANSCODER_MIPI_C";
case POWER_DOMAIN_PORT_DDI_A_LANES:
return "PORT_DDI_A_LANES";
case POWER_DOMAIN_PORT_DDI_B_LANES:
@@ -403,6 +407,8 @@ static void hsw_set_power_well(struct drm_i915_private 
*dev_priv,
BXT_DISPLAY_POWERWELL_2_POWER_DOMAINS | \
BIT(POWER_DOMAIN_PIPE_A) |  \
BIT(POWER_DOMAIN_TRANSCODER_EDP) |  \
+   BIT(POWER_DOMAIN_TRANSCODER_MIPI_A) |   \
+   BIT(POWER_DOMAIN_TRANSCODER_MIPI_C) |   \
BIT(POWER_DOMAIN_PIPE_A_PANEL_FITTER) | \
BIT(POWER_DOMAIN_PORT_DDI_A_LANES) |\
BIT(POWER_DOMAIN_AUX_A) |   \
-- 
1.7.9.5

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

Re: [Intel-gfx] [REGRESSION] i915: No HDMI output with 4.4

[Ville Syrjälä]

On Mon, Feb 22, 2016 at 02:32:32PM +0200, Oleksandr Natalenko wrote:
> Ville, Daniel,
> 
> any additional info I could provide? I have to return dual-link DVI 
> cable back, so let me know if I could reveal more details if necessary.

Unfortunately I'm out of ideas for now. Daniel is on vacation.
Anyone else? VPG folks should take the ball here since they broke it.

In the meantime I think as a workaround I think you could use
something like video=HDMI-A-1:e on the kernel command line (not sure
I got the connector name right for your system). I think that should
result in the live status check to be skipped, at least when
populating the mode list.

Might be a good idea to collect all the information here and put in a
bug report (https://bugs.freedesktop.org/ -> DRI -> DRM/Intel) so that
all the logs and such would be in one place.

> 
> Regards,
>Oleksandr
> 
> 16.02.2016 14:54, Daniel Vetter написав:
> > On Tue, Feb 16, 2016 at 12:58:56PM +0200, Oleksandr Natalenko wrote:
> >> Ville, Daniel,
> >> 
> >> I've just got another monitor and another DVI-HDMI cable, and here 
> >> what I've
> >> got.
> >> 
> >> ===Single Link DVI-D cable with 3 different monitors===
> >> 
> >> Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI LG 23MP65HQ-P 
> >> ===
> >> not working
> > 
> > I presume the above LG screen is what you've called previously "old
> > monitor"?
> > 
> >> Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI LG 23MP67HQ-P 
> >> ===
> >> not working
> >> Computer DVI ——— DVI-D (Single Link)/HDMI cable ——— HDMI LG 23MP55HQ-P 
> >> ===
> >> works!
> >> 
> >> ===Dual Link DVI-D cable with monitor that doesn't work with Single 
> >> Link
> >> cable===
> >> 
> >> Computer DVI ——— DVI-D (Dual Link)/HDMI cable ——— HDMI LG 23MP65HQ-P 
> >> ===
> >> works!
> > 
> > Funky. Can you pls grab the debug logs (with the special patches from
> > Ville) for this case? I wonder why suddenly different cable and it 
> > works.
> > 
> > Also: Is this one of these older-ish screens where you must have a
> > dual-link cable to drive it at full resolution rate?
> > -Daniel
> > 
> > 
> >> ===Laptop with HDMI output===
> >> 
> >> Laptop HDMI ——— HDMI/HDMI cable ——— HDMI LG 23MP65HQ-P === works!
> >> 
> >> I'd say that single link DVI cables are broken with new kernel, but 
> >> one of
> >> monitors could work with such a cable. So I have no idea :(.
> >> 
> >> Regards,
> >>   Oleksandr.
> >> 
> >> 15.02.2016 17:42, Daniel Vetter wrote:
> >> >The other downside is that it'll make us non-compliant, which was the
> >> >point of this entire ordeal: HDMI spec forbids us from starting any i2c
> >> >transactions when the hpd isn't signalling a present screen.
> >> >
> >> >So maybe we need to buy one of these broken screens.
> >> >
> >> >Oleksandr, what exact model are you using? And any chance that you could
> >> >test this on some other machine with intel gfx and latest kernel, just to
> >> >make sure this really is some issue with the sink and not with the machine
> >> >itself? And I guess you've tested with some other hdmi sink, and that
> >> >works?

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

Re: [Intel-gfx] [RFC] drm/i915: Check if we hold a wakeref during ioread32/iowrite32

[Chris Wilson]

On Tue, Feb 23, 2016 at 04:47:17PM +0200, Imre Deak wrote:
> The device needs to be in D0 state whenever we call these functions, so
> add the corresponding assert checks.

No. In quite a few of those cases we are calling iowrite to non-device
memory, even normal pages.

How's the separation of struct_mutex from rpm going so that we can forgo
adding assertions and use explicit power management instead?
-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] [RFC] drm/i915: Check if we hold a wakeref during ioread32/iowrite32

[Imre Deak]

The device needs to be in D0 state whenever we call these functions, so
add the corresponding assert checks.

I had to move around some helpers due to dependencies added by nested
includes.

Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/i915_drv.h| 117 +
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |   4 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c|   8 +-
 drivers/gpu/drm/i915/i915_irq.c|   8 +-
 drivers/gpu/drm/i915/intel_bios.c  |   7 +-
 drivers/gpu/drm/i915/intel_drv.h   |  75 --
 drivers/gpu/drm/i915/intel_lrc.c   |   3 +-
 drivers/gpu/drm/i915/intel_lrc.h   |  17 -
 drivers/gpu/drm/i915/intel_overlay.c   |  44 ++-
 drivers/gpu/drm/i915/intel_ringbuffer.c|   3 +-
 drivers/gpu/drm/i915/intel_ringbuffer.h|  13 +---
 11 files changed, 161 insertions(+), 138 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9e76bfc..c794664 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3509,6 +3509,123 @@ int intel_freq_opcode(struct drm_i915_private 
*dev_priv, int val);
 #define I915_READ_NOTRACE(reg) 
dev_priv->uncore.funcs.mmio_readl(dev_priv, (reg), false)
 #define I915_WRITE_NOTRACE(reg, val)   
dev_priv->uncore.funcs.mmio_writel(dev_priv, (reg), (val), false)
 
+static inline void
+assert_rpm_device_not_suspended(struct drm_i915_private *dev_priv)
+{
+   WARN_ONCE(dev_priv->pm.suspended,
+ "Device suspended during HW access\n");
+}
+
+static inline void
+assert_rpm_wakelock_held(struct drm_i915_private *dev_priv)
+{
+   assert_rpm_device_not_suspended(dev_priv);
+   /* FIXME: Needs to be converted back to WARN_ONCE, but currently causes
+* too much noise. */
+   if (!atomic_read(_priv->pm.wakeref_count))
+   DRM_DEBUG_DRIVER("RPM wakelock ref not held during HW access");
+}
+
+static inline int
+assert_rpm_atomic_begin(struct drm_i915_private *dev_priv)
+{
+   int seq = atomic_read(_priv->pm.atomic_seq);
+
+   assert_rpm_wakelock_held(dev_priv);
+
+   return seq;
+}
+
+static inline void
+assert_rpm_atomic_end(struct drm_i915_private *dev_priv, int begin_seq)
+{
+   WARN_ONCE(atomic_read(_priv->pm.atomic_seq) != begin_seq,
+ "HW access outside of RPM atomic section\n");
+}
+
+/**
+ * disable_rpm_wakeref_asserts - disable the RPM assert checks
+ * @dev_priv: i915 device instance
+ *
+ * This function disable asserts that check if we hold an RPM wakelock
+ * reference, while keeping the device-not-suspended checks still enabled.
+ * It's meant to be used only in special circumstances where our rule about
+ * the wakelock refcount wrt. the device power state doesn't hold. According
+ * to this rule at any point where we access the HW or want to keep the HW in
+ * an active state we must hold an RPM wakelock reference acquired via one of
+ * the intel_runtime_pm_get() helpers. Currently there are a few special spots
+ * where this rule doesn't hold: the IRQ and suspend/resume handlers, the
+ * forcewake release timer, and the GPU RPS and hangcheck works. All other
+ * users should avoid using this function.
+ *
+ * Any calls to this function must have a symmetric call to
+ * enable_rpm_wakeref_asserts().
+ */
+static inline void
+disable_rpm_wakeref_asserts(struct drm_i915_private *dev_priv)
+{
+   atomic_inc(_priv->pm.wakeref_count);
+}
+
+/**
+ * enable_rpm_wakeref_asserts - re-enable the RPM assert checks
+ * @dev_priv: i915 device instance
+ *
+ * This function re-enables the RPM assert checks after disabling them with
+ * disable_rpm_wakeref_asserts. It's meant to be used only in special
+ * circumstances otherwise its use should be avoided.
+ *
+ * Any calls to this function must have a symmetric call to
+ * disable_rpm_wakeref_asserts().
+ */
+static inline void
+enable_rpm_wakeref_asserts(struct drm_i915_private *dev_priv)
+{
+   atomic_dec(_priv->pm.wakeref_count);
+}
+
+
+#define I915_IOWRITE32(val, addr) ({   \
+   assert_rpm_wakelock_held(dev_priv); \
+   iowrite32(val, addr); })
+
+#define I915_IOREAD32(addr) ({ \
+   assert_rpm_wakelock_held(dev_priv); \
+   ioread32(addr); })
+
+static inline void intel_ring_emit(struct intel_engine_cs *ring,
+  u32 data)
+{
+   struct drm_i915_private *dev_priv = to_i915(ring->dev);
+   struct intel_ringbuffer *ringbuf = ring->buffer;
+
+   I915_IOWRITE32(data, ringbuf->virtual_start + ringbuf->tail);
+   ringbuf->tail += 4;
+}
+static inline void intel_ring_emit_reg(struct intel_engine_cs *ring,
+  i915_reg_t reg)
+{
+   intel_ring_emit(ring, i915_mmio_reg_offset(reg));
+}
+/**
+ * intel_logical_ring_emit() - write a DWORD to the ringbuffer.
+ * @ringbuf: Ringbuffer 

Re: [Intel-gfx] [PATCH] drm/i915/lrc: Only set RS ctx enable in ctx control reg if there is a RS

[Arun Siluvery]

On 23/02/2016 13:56, Michel Thierry wrote:

The driver should only set the "RS context enable" bit in the context
image if we plan to use the resource streamer.

Signed-off-by: Michel Thierry 
---
  drivers/gpu/drm/i915/intel_lrc.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index e12fcab..c3779b9 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2382,7 +2382,8 @@ populate_lr_context(struct intel_context *ctx, struct 
drm_i915_gem_object *ctx_o
ASSIGN_CTX_REG(reg_state, CTX_CONTEXT_CONTROL, 
RING_CONTEXT_CONTROL(ring),
   _MASKED_BIT_ENABLE(CTX_CTRL_INHIBIT_SYN_CTX_SWITCH |
  CTX_CTRL_ENGINE_CTX_RESTORE_INHIBIT |
- CTX_CTRL_RS_CTX_ENABLE));
+ (HAS_RESOURCE_STREAMER(dev) ?
+   CTX_CTRL_RS_CTX_ENABLE : 0)));
ASSIGN_CTX_REG(reg_state, CTX_RING_HEAD, RING_HEAD(ring->mmio_base), 0);
ASSIGN_CTX_REG(reg_state, CTX_RING_TAIL, RING_TAIL(ring->mmio_base), 0);
/* Ring buffer start address is not known until the buffer is pinned.



looks good to me,
Reviewed-by: Arun Siluvery 

regards
Arun


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

Re: [Intel-gfx] [BUG] HDMI 12bpc causing occasional flickering and blanking

[Ville Syrjälä]

On Fri, Feb 19, 2016 at 08:55:02PM +0100, Tore Anderson wrote:
> * Tore Anderson
> 
> > * Ville Syrjälä
> > 
> > > Could you test the following hack while using a 1920x1080 mode with
> > > 148.5 MHz dotclock, and see if there's any improvement?  
> > 
> > I think it might be an improvement, that is, the blanking/flickers
> > seems to occur less often than it did with 8ed1804, but it is not
> > completely fixed.
> 
> Hi again Ville,
> 
> I spoke too soon. I've been doing some more testing with current Git
> master (e7d04bf). I'm now certain that your patch makes no difference
> whatsoever, the flickering/blanking is just as bad as before.
> 
> The intensity/frequency of the problems vary significantly, so when I
> tested your patch previously I must have hit one of the better periods.
> As I write this, however, the computer is essentially rendered
> unusable. (I have no idea what causes this variance, unfortunately.)
> 
> Do you (or anyone else for that matter) have any other ideas?

"The monitor is connected with a DP+-to-HDMI cable"
This and some reading of the DP dual mode spec gave me another idea;
The DP->HDMI adaptor may simply be degrading the signal quality too
much. According to the DP dual mode spec we're supposed to limit the
TMDS clock based on the type of adapter used, but currently we have
no code to do that. I've cooked up a few patches that should do what
we want:
git://github.com/vsyrjala/linux.git dp_dual_mode

I've quickly tested it locally, and it seemed to do the right thing
with a few different types of adaptors.

> 
> By the way: Is it possible to disable HDMI 12bpc in a way that doesn't
> require me to patch and rebuild the kernel drivers, such as a kernel
> module parameter or sysfs setting? (I prefer to simply use the upstream
> Fedora kernel RPMs, but this issue is currently making that impossible.)

We don't have any knob to control this.

There is at least one way to do it though, but it's quite involved. What
you would need to do is dump the EDID, modify it to indicate that 12bpc
isn't supported (and fix up the CRC), and then use the firmware EDID
mechanism to override the EDID with the hacked up version.

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

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Implement color management on bdw/skl/bxt/kbl

[Lionel Landwerlin]

On 23/02/16 00:52, Matt Roper wrote:

On Mon, Feb 22, 2016 at 02:18:10PM +, Lionel Landwerlin wrote:

Patch based on a previous series by Shashank Sharma.

v2: Do not read GAMMA_MODE register to figure what mode we're in

v3: Program PREC_PAL_GC_MAX to clamp pixel values > 1.0

 Add documentation on how the Broadcast RGB property is affected by CTM

v4: Update contributors

v5: Refactor degamma/gamma LUTs load into a single function

v6: Fix missing intel_crtc variable (bisect issue)

Not sure if you saw me feedback on v4 or not:
https://lists.freedesktop.org/archives/intel-gfx/2016-February/088043.html

It looks like most of those comments still apply here.  If you disagree
with my comments, that's fine too, I just wanted to make sure it didn't
get overlooked.  :-)


Matt


Sorry for that, completely missed on the first 3/4 comments.
You're right the limited range multiplication was wrong (input[i] vs 
result[i]...).

Fixed that and simplified it as you suggested.

Thanks a lot!

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

Re: [Intel-gfx] [PATCH v2] drm/i915: Avoid selecting unavailable BSD2 ring

[Tvrtko Ursulin]

On 23/02/16 14:03, Chris Wilson wrote:

On Tue, Feb 23, 2016 at 01:31:17PM +, Tvrtko Ursulin wrote:


On 23/02/16 13:06, Gabriel Feceoru wrote:



On 23.02.2016 13:05, Tvrtko Ursulin wrote:


Hi,

On 23/02/16 10:52, Gabriel Feceoru wrote:

Return error when I915_EXEC_BSD_RING2 flag is set but BSD2 ring
is not available in the HW.


What is the reasoning behind this? So far kernel was allowing userspace
to select these bits and execute on the first engine. With this patch it
would start failing potentially breaking userspace. Is it not too late
to make such change?


I noticed some inconsistencies in igt with regards to bsd and bsd1.
For instance, if bsd2 is not available, gem_sync@basic-bsd1 is skipped,
but it's skipped because of the 2nd check gem_has_bsd2 (see
gem_require_ring). Surprisingly gem_has_ring() didn't complain about bsd1.

This fix will make gem_has_ring() return false.

I'm not aware about legacy/compatibility issue - if that's the case,
please disregard this.


Hmmm.. Chris, what is the reasoning behind:

commit eaa03678b00179da89f194113c0740c033857c1c
Author: Chris Wilson 
Date:   Thu Jan 28 13:44:19 2016 +

 lib: Hide BSD1/BSD2 rings on hardware without BSD2

 The kernel happily lets us run on I915_EXEC_BSD2 even with such hardware
 existing. Sigh.

 Signed-off-by: Chris Wilson 

diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
index 9dfa9b2603ce..fa44080e5902 100644
--- a/lib/ioctl_wrappers.c
+++ b/lib/ioctl_wrappers.c
@@ -1341,6 +1341,12 @@ static int gem_has_ring(int fd, int ring)
  void gem_require_ring(int fd, int ring_id)
  {
 igt_require(gem_has_ring(fd, ring_id));
+
+   /* silly ABI, the kernel thinks everyone who has BSD also has BSD2 */
+   if ((ring_id & ~(3<<13)) == I915_EXEC_BSD) {
+   if (ring_id & (3 << 13))
+   igt_require(gem_has_bsd2(fd));
+   }
  }

  /* prime */

ABI was (and still is) that specifying BSD1 or BSD2 explicitly is
silently ignored by the kernel when BSD2 is not preset, defaulting
to BSD1.


Thereby pretending that BSD, BSD1, BSD2 exist.


This patch makes tests requesting BSD1 skip when there is no BSD2
which I think is wrong in any case.


BSD 1/2 selection only makes sense when we have multiple BSD rings.
Running tests on BSD default, BSD1 and BSD2 is pointless if they all
are equivalent. Using the BSD ping-pong when we have BSD1 and BSD2 is
questionable as the ping-pong nature is uncontrolled, but nevertheless
the code path needs to be tested.


If we want to (and can) change the ABI it should only reject the
non-existent ring and not limit the selection mechanism to
hardware which has BSD2.


I disagree, we have a ring selection mechanism. If the extension doesn't
exist, trying to use it should be an error. The extension was not only
an ABI mistake but undesired (it is now defunct).


Not sure that I understand what you meant here. Nothing as far as I can 
tell is now defunct. Neither the selection mechanism, or the existence 
of BSD2.


To be absolutely clear, you are, or you are not, in favour of Gabriel's 
patch to start failing execbuf with fine grained BSD selection flags 
when BSD2 is not present?


Regards,

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

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Updating the CPU_TRANSCODER for BXT DSI

[Ramalingam C]

On Friday 19 February 2016 02:37 PM, Jani Nikula wrote:

On Thu, 11 Feb 2016, Ramalingam C  wrote:

In case of BXT DSI we are updating the CPU_TRANSCODER
with appropriate value.

Signed-off-by: Ramalingam C 
Signed-off-by: Uma Shankar 
---
  drivers/gpu/drm/i915/i915_drv.h  |2 ++
  drivers/gpu/drm/i915/intel_display.c |5 +
  2 files changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 65a2cd0..ef4b376 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -122,6 +122,8 @@ enum transcoder {
TRANSCODER_B,
TRANSCODER_C,
TRANSCODER_EDP,
+   TRANSCODER_MIPI_A,
+   TRANSCODER_MIPI_C,
I915_MAX_TRANSCODERS
  };
  #define transcoder_name(t) ((t) + 'A')
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index e47a75c..9715056 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7851,6 +7851,11 @@ static void intel_get_dsi_pipe_timings(struct intel_crtc 
*crtc,
enc_to_intel_dsi(>base);
pipe_config->pipe_bpp =
dsi_pixel_format_bpp(intel_dsi->pixel_format);
+
+   if (intel_dsi->ports & (1 << PORT_A))
+   pipe_config->cpu_transcoder = TRANSCODER_MIPI_A;
+   else
+   pipe_config->cpu_transcoder = TRANSCODER_MIPI_C;
}
}

As I've said in my review of the previous version of the patch [1], you
can't just add transcoder identifiers and expect everything to magically
work.

The current assumption is there are at most transcoders A, B, C, and
eDP. We use them to index registers. Not all registers have a
corresponding DSI transcoder variant, and if they do, they are not
uniformly spread in the register offset space. See haswell_crtc_disable
for an example where things go wrong. There are others.

I do not know what the best approach here would be; it is obvious to me
this can't work.

As correcting the CPU transcoder value alone wont solve our problem.
In the next patch set I am adding corresponding POWER_DOMAIN bits
and adding them to the respective POWER wells. This will enable generic 
power well

management calls to map the cpu transcoders to the corresponding powerwell
and help them to maintain them as per the need. Hope that will address 
the concern raised here.


BR,
Jani.


[1] http://mid.gmane.org/87powceh4r@intel.com





--
Thanks,
--Ram

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

[Intel-gfx] [PATCH 5/5] drm/i915: Implement color management on chv

[Lionel Landwerlin]

Patch based on a previous series by Shashank Sharma.

v2: Update contributors

v3: Refactor degamma/gamma LUTs load into a single function

v4: Remove unused variable

Signed-off-by: Shashank Sharma 
Signed-off-by: Lionel Landwerlin 
Signed-off-by: Kumar, Kiran S 
Signed-off-by: Kausal Malladi 
---
 drivers/gpu/drm/i915/i915_drv.c|   3 +
 drivers/gpu/drm/i915/i915_reg.h|  31 +
 drivers/gpu/drm/i915/intel_color.c | 133 +++--
 3 files changed, 161 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 3807b73..8a2aaa7 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -68,6 +68,8 @@ static struct drm_driver driver;
 
 #define BDW_COLORS \
.color = { .degamma_lut_size = 512, .gamma_lut_size = 512 }
+#define CHV_COLORS \
+   .color = { .degamma_lut_size = 65, .gamma_lut_size = 257 }
 
 static const struct intel_device_info intel_i830_info = {
.gen = 2, .is_mobile = 1, .cursor_needs_physical = 1, .num_pipes = 2,
@@ -325,6 +327,7 @@ static const struct intel_device_info intel_cherryview_info 
= {
.display_mmio_offset = VLV_DISPLAY_BASE,
GEN_CHV_PIPEOFFSETS,
CURSOR_OFFSETS,
+   CHV_COLORS,
 };
 
 static const struct intel_device_info intel_skylake_info = {
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8ce76d7..effd79e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7672,6 +7672,37 @@ enum skl_disp_power_wells {
 #define PREC_PAL_GC_MAX(pipe, i)   _MMIO(_PIPE(pipe, _PAL_PREC_GC_MAX_A, 
_PAL_PREC_GC_MAX_B) + (i) * 4)
 #define PREC_PAL_EXT_GC_MAX(pipe, i)   _MMIO(_PIPE(pipe, 
_PAL_PREC_EXT_GC_MAX_A, _PAL_PREC_EXT_GC_MAX_B) + (i) * 4)
 
+/* pipe CSC & degamma/gamma LUTs on CHV */
+#define _CGM_PIPE_A_CSC_COEFF01(VLV_DISPLAY_BASE + 0x67900)
+#define _CGM_PIPE_A_CSC_COEFF23(VLV_DISPLAY_BASE + 0x67904)
+#define _CGM_PIPE_A_CSC_COEFF45(VLV_DISPLAY_BASE + 0x67908)
+#define _CGM_PIPE_A_CSC_COEFF67(VLV_DISPLAY_BASE + 0x6790C)
+#define _CGM_PIPE_A_CSC_COEFF8 (VLV_DISPLAY_BASE + 0x67910)
+#define _CGM_PIPE_A_DEGAMMA(VLV_DISPLAY_BASE + 0x66000)
+#define _CGM_PIPE_A_GAMMA  (VLV_DISPLAY_BASE + 0x67000)
+#define _CGM_PIPE_A_MODE   (VLV_DISPLAY_BASE + 0x67A00)
+#define   CGM_PIPE_MODE_GAMMA  (1 << 2)
+#define   CGM_PIPE_MODE_CSC(1 << 1)
+#define   CGM_PIPE_MODE_DEGAMMA(1 << 0)
+
+#define _CGM_PIPE_B_CSC_COEFF01(VLV_DISPLAY_BASE + 0x69900)
+#define _CGM_PIPE_B_CSC_COEFF23(VLV_DISPLAY_BASE + 0x69904)
+#define _CGM_PIPE_B_CSC_COEFF45(VLV_DISPLAY_BASE + 0x69908)
+#define _CGM_PIPE_B_CSC_COEFF67(VLV_DISPLAY_BASE + 0x6990C)
+#define _CGM_PIPE_B_CSC_COEFF8 (VLV_DISPLAY_BASE + 0x69910)
+#define _CGM_PIPE_B_DEGAMMA(VLV_DISPLAY_BASE + 0x68000)
+#define _CGM_PIPE_B_GAMMA  (VLV_DISPLAY_BASE + 0x69000)
+#define _CGM_PIPE_B_MODE   (VLV_DISPLAY_BASE + 0x69A00)
+
+#define CGM_PIPE_CSC_COEFF01(pipe) _MMIO_PIPE(pipe, 
_CGM_PIPE_A_CSC_COEFF01, _CGM_PIPE_B_CSC_COEFF01)
+#define CGM_PIPE_CSC_COEFF23(pipe) _MMIO_PIPE(pipe, 
_CGM_PIPE_A_CSC_COEFF23, _CGM_PIPE_B_CSC_COEFF23)
+#define CGM_PIPE_CSC_COEFF45(pipe) _MMIO_PIPE(pipe, 
_CGM_PIPE_A_CSC_COEFF45, _CGM_PIPE_B_CSC_COEFF45)
+#define CGM_PIPE_CSC_COEFF67(pipe) _MMIO_PIPE(pipe, 
_CGM_PIPE_A_CSC_COEFF67, _CGM_PIPE_B_CSC_COEFF67)
+#define CGM_PIPE_CSC_COEFF8(pipe)  _MMIO_PIPE(pipe, 
_CGM_PIPE_A_CSC_COEFF8, _CGM_PIPE_B_CSC_COEFF8)
+#define CGM_PIPE_DEGAMMA(pipe, i, w)   _MMIO(_PIPE(pipe, _CGM_PIPE_A_DEGAMMA, 
_CGM_PIPE_B_DEGAMMA) + (i) * 8 + (w) * 4)
+#define CGM_PIPE_GAMMA(pipe, i, w) _MMIO(_PIPE(pipe, _CGM_PIPE_A_GAMMA, 
_CGM_PIPE_B_GAMMA) + (i) * 8 + (w) * 4)
+#define CGM_PIPE_MODE(pipe)_MMIO_PIPE(pipe, _CGM_PIPE_A_MODE, 
_CGM_PIPE_B_MODE)
+
 /* MIPI DSI registers */
 
 #define _MIPI_PORT(port, a, c) _PORT3(port, a, 0, c)   /* ports A and C only */
diff --git a/drivers/gpu/drm/i915/intel_color.c 
b/drivers/gpu/drm/i915/intel_color.c
index 97a047b..6999fd3 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -29,6 +29,7 @@
 #define CTM_COEFF_1_0  (1ULL << 32)
 #define CTM_COEFF_2_0  (CTM_COEFF_1_0 << 1)
 #define CTM_COEFF_4_0  (CTM_COEFF_2_0 << 1)
+#define CTM_COEFF_8_0  (CTM_COEFF_4_0 << 1)
 #define CTM_COEFF_0_5  (CTM_COEFF_1_0 >> 1)
 #define CTM_COEFF_0_25 (CTM_COEFF_0_5 >> 1)
 #define CTM_COEFF_0_125(CTM_COEFF_0_25 >> 1)
@@ -199,6 +200,58 @@ static void i9xx_load_csc_matrix(struct drm_crtc *crtc)
}
 }
 
+/*
+ * Set up the pipe CSC unit on CherryView.
+ */
+static void cherryview_load_csc_matrix(struct drm_crtc *crtc)
+{
+   struct drm_device *dev = crtc->dev;
+   struct drm_crtc_state *state = crtc->state;
+   struct 

[Intel-gfx] [PATCH 2/5] drm/i915: Do not read GAMMA_MODE register

[Lionel Landwerlin]

Implement Daniel Stone's recommendation to not read registers to infer
the hardware's state.

v2: Read GAMMA_MODE register value at init

Signed-off-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/intel_color.c | 17 +
 drivers/gpu/drm/i915/intel_drv.h   |  3 +++
 2 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_color.c 
b/drivers/gpu/drm/i915/intel_color.c
index 5e0b997..f6bf9f1 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -121,6 +121,8 @@ static void haswell_load_luts(struct drm_crtc *crtc)
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   struct intel_crtc_state *intel_crtc_state =
+   to_intel_crtc_state(crtc->state);
bool reenable_ips = false;
 
/*
@@ -128,11 +130,12 @@ static void haswell_load_luts(struct drm_crtc *crtc)
 * GAMMA_MODE is configured for split gamma and IPS_CTL has IPS enabled.
 */
if (IS_HASWELL(dev) && intel_crtc->config->ips_enabled &&
-   ((I915_READ(GAMMA_MODE(intel_crtc->pipe)) & GAMMA_MODE_MODE_MASK) ==
-GAMMA_MODE_MODE_SPLIT)) {
+   (intel_crtc_state->gamma_mode == GAMMA_MODE_MODE_SPLIT)) {
hsw_disable_ips(intel_crtc);
reenable_ips = true;
}
+
+   intel_crtc_state->gamma_mode = GAMMA_MODE_MODE_8BIT;
I915_WRITE(GAMMA_MODE(intel_crtc->pipe), GAMMA_MODE_MODE_8BIT);
 
i9xx_load_luts(crtc);
@@ -173,6 +176,8 @@ void intel_color_init(struct drm_crtc *crtc)
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   struct intel_crtc_state *intel_crtc_state =
+   to_intel_crtc_state(crtc->state);
int i;
 
drm_mode_crtc_set_gamma_size(crtc, 256);
@@ -183,8 +188,12 @@ void intel_color_init(struct drm_crtc *crtc)
}
 
if (IS_HASWELL(dev) ||
-   (INTEL_INFO(dev)->gen >= 8 && !IS_CHERRYVIEW(dev)))
+   (INTEL_INFO(dev)->gen >= 8 && !IS_CHERRYVIEW(dev))) {
dev_priv->display.load_luts = haswell_load_luts;
-   else
+
+   intel_crtc_state->gamma_mode =
+   I915_READ(GAMMA_MODE(intel_crtc->pipe));
+   } else {
dev_priv->display.load_luts = i9xx_load_luts;
+   }
 }
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 40fc486..9742d5b 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -517,6 +517,9 @@ struct intel_crtc_state {
struct skl_pipe_wm skl;
} optimal;
} wm;
+
+   /* Gamma mode programmed on the pipe */
+   uint32_t gamma_mode;
 };
 
 struct vlv_wm_state {
-- 
2.7.0

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

[Intel-gfx] [PATCH 0/5] Pipe level color management V7

[Lionel Landwerlin]

This series introduces pipe level color management through a set of properties
attached to the CRTC. It also provides an implementation for some Intel
platforms.

This series is based of a previous set of patches by Shashank Sharma.

Cheers,

Lionel

Lionel Landwerlin (5):
  drm/i915: Extract out gamma table and CSC to their own file
  drm/i915: Do not read GAMMA_MODE register
  drm: introduce pipe color correction properties
  drm/i915: Implement color management on bdw/skl/bxt/kbl
  drm/i915: Implement color management on chv

 Documentation/DocBook/gpu.tmpl   |  65 +++-
 drivers/gpu/drm/drm_atomic.c |  86 +-
 drivers/gpu/drm/drm_atomic_helper.c  | 103 +++
 drivers/gpu/drm/drm_crtc.c   |  35 +++
 drivers/gpu/drm/drm_crtc_helper.c|  33 ++
 drivers/gpu/drm/i915/Makefile|   1 +
 drivers/gpu/drm/i915/i915_drv.c  |  27 +-
 drivers/gpu/drm/i915/i915_drv.h  |   8 +
 drivers/gpu/drm/i915/i915_reg.h  |  53 
 drivers/gpu/drm/i915/intel_color.c   | 563 +++
 drivers/gpu/drm/i915/intel_display.c | 181 ++-
 drivers/gpu/drm/i915/intel_drv.h |  12 +
 drivers/gpu/drm/i915/intel_fbdev.c   |   8 +
 include/drm/drm_atomic_helper.h  |   3 +
 include/drm/drm_crtc.h   |  46 ++-
 include/drm/drm_crtc_helper.h|   3 +
 include/uapi/drm/drm_mode.h  |  15 +
 17 files changed, 1077 insertions(+), 165 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_color.c

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

[Intel-gfx] [PATCH 4/5] drm/i915: Implement color management on bdw/skl/bxt/kbl

[Lionel Landwerlin]

Patch based on a previous series by Shashank Sharma.

v2: Do not read GAMMA_MODE register to figure what mode we're in

v3: Program PREC_PAL_GC_MAX to clamp pixel values > 1.0

Add documentation on how the Broadcast RGB property is affected by CTM

v4: Update contributors

v5: Refactor degamma/gamma LUTs load into a single function

v6: Fix missing intel_crtc variable (bisect issue)

v7: Fix & simplify limited range matrix multiplication

Signed-off-by: Shashank Sharma 
Signed-off-by: Lionel Landwerlin 
Signed-off-by: Kumar, Kiran S 
Signed-off-by: Kausal Malladi 
---
 Documentation/DocBook/gpu.tmpl   |   6 +-
 drivers/gpu/drm/i915/i915_drv.c  |  24 ++-
 drivers/gpu/drm/i915/i915_drv.h  |   6 +
 drivers/gpu/drm/i915/i915_reg.h  |  22 +++
 drivers/gpu/drm/i915/intel_color.c   | 343 ++-
 drivers/gpu/drm/i915/intel_display.c |  22 ++-
 drivers/gpu/drm/i915/intel_drv.h |   3 +-
 drivers/gpu/drm/i915/intel_fbdev.c   |   8 +
 8 files changed, 371 insertions(+), 63 deletions(-)

diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
index 1692c4d..430e99b 100644
--- a/Documentation/DocBook/gpu.tmpl
+++ b/Documentation/DocBook/gpu.tmpl
@@ -2153,7 +2153,11 @@ void intel_crt_init(struct drm_device *dev)
ENUM
{ "Automatic", "Full", "Limited 16:235" }
Connector
-   TBD
+   When this property is set to Limited 16:235
+   and CTM is set, the hardware will be programmed with the
+   result of the multiplication of CTM by the limited range
+   matrix to ensure the pixels normaly in the range 0..1.0 are
+   remapped to the range 16/255..235/255.


“audio”
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 20e8200..3807b73 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -66,6 +66,9 @@ static struct drm_driver driver;
 #define IVB_CURSOR_OFFSETS \
.cursor_offsets = { CURSOR_A_OFFSET, IVB_CURSOR_B_OFFSET, 
IVB_CURSOR_C_OFFSET }
 
+#define BDW_COLORS \
+   .color = { .degamma_lut_size = 512, .gamma_lut_size = 512 }
+
 static const struct intel_device_info intel_i830_info = {
.gen = 2, .is_mobile = 1, .cursor_needs_physical = 1, .num_pipes = 2,
.has_overlay = 1, .overlay_needs_physical = 1,
@@ -288,24 +291,28 @@ static const struct intel_device_info 
intel_haswell_m_info = {
.is_mobile = 1,
 };
 
+#define BDW_FEATURES \
+   HSW_FEATURES, \
+   BDW_COLORS
+
 static const struct intel_device_info intel_broadwell_d_info = {
-   HSW_FEATURES,
+   BDW_FEATURES,
.gen = 8,
 };
 
 static const struct intel_device_info intel_broadwell_m_info = {
-   HSW_FEATURES,
+   BDW_FEATURES,
.gen = 8, .is_mobile = 1,
 };
 
 static const struct intel_device_info intel_broadwell_gt3d_info = {
-   HSW_FEATURES,
+   BDW_FEATURES,
.gen = 8,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
 };
 
 static const struct intel_device_info intel_broadwell_gt3m_info = {
-   HSW_FEATURES,
+   BDW_FEATURES,
.gen = 8, .is_mobile = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
 };
@@ -321,13 +328,13 @@ static const struct intel_device_info 
intel_cherryview_info = {
 };
 
 static const struct intel_device_info intel_skylake_info = {
-   HSW_FEATURES,
+   BDW_FEATURES,
.is_skylake = 1,
.gen = 9,
 };
 
 static const struct intel_device_info intel_skylake_gt3_info = {
-   HSW_FEATURES,
+   BDW_FEATURES,
.is_skylake = 1,
.gen = 9,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
@@ -345,17 +352,18 @@ static const struct intel_device_info intel_broxton_info 
= {
.has_fbc = 1,
GEN_DEFAULT_PIPEOFFSETS,
IVB_CURSOR_OFFSETS,
+   BDW_COLORS,
 };
 
 static const struct intel_device_info intel_kabylake_info = {
-   HSW_FEATURES,
+   BDW_FEATURES,
.is_preliminary = 1,
.is_kabylake = 1,
.gen = 9,
 };
 
 static const struct intel_device_info intel_kabylake_gt3_info = {
-   HSW_FEATURES,
+   BDW_FEATURES,
.is_preliminary = 1,
.is_kabylake = 1,
.gen = 9,
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6634c09..7627a4e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -660,6 +660,7 @@ struct drm_i915_display_funcs {
/* display clock increase/decrease */
/* pll clock increase/decrease */
 
+   void (*load_csc_matrix)(struct drm_crtc *crtc);
void (*load_luts)(struct drm_crtc *crtc);
 };
 
@@ -808,6 +809,11 @@ struct intel_device_info {
u8 has_slice_pg:1;
u8 

[Intel-gfx] [PATCH 3/5] drm: introduce pipe color correction properties

[Lionel Landwerlin]

Patch based on a previous series by Shashank Sharma.

This introduces optional properties to enable color correction at the
pipe level. It relies on 3 transformations applied to every pixels
displayed. First a lookup into a degamma table, then a multiplication
of the rgb components by a 3x3 matrix and finally another lookup into
a gamma table.

The following properties can be added to a pipe :
  - DEGAMMA_LUT : blob containing degamma LUT
  - DEGAMMA_LUT_SIZE : number of elements in DEGAMMA_LUT
  - CTM : transformation matrix applied after the degamma LUT
  - GAMMA_LUT : blob containing gamma LUT
  - GAMMA_LUT_SIZE : number of elements in GAMMA_LUT

DEGAMMA_LUT_SIZE and GAMMA_LUT_SIZE are read only properties, set by
the driver to tell userspace applications what sizes should be the
lookup tables in DEGAMMA_LUT and GAMMA_LUT.

A helper is also provided so legacy gamma correction is redirected
through these new properties.

v2: Register LUT size properties as range

v3: Fix round in drm_color_lut_get_value() helper
More docs on how degamma/gamma properties are used

v4: Update contributors

v5: Rename CTM_MATRIX property to CTM (Doh!)
Add legacy gamma_set atomic helper
Describe CTM/LUT acronyms in the kernel doc

Signed-off-by: Shashank Sharma 
Signed-off-by: Lionel Landwerlin 
Signed-off-by: Kumar, Kiran S 
Signed-off-by: Kausal Malladi 
Reviewed-by: Matt Roper 
---
 Documentation/DocBook/gpu.tmpl  |  59 -
 drivers/gpu/drm/drm_atomic.c|  86 +-
 drivers/gpu/drm/drm_atomic_helper.c | 103 
 drivers/gpu/drm/drm_crtc.c  |  35 
 drivers/gpu/drm/drm_crtc_helper.c   |  33 
 include/drm/drm_atomic_helper.h |   3 ++
 include/drm/drm_crtc.h  |  46 +++-
 include/drm/drm_crtc_helper.h   |   3 ++
 include/uapi/drm/drm_mode.h |  15 ++
 9 files changed, 378 insertions(+), 5 deletions(-)

diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
index fe6b36a..1692c4d 100644
--- a/Documentation/DocBook/gpu.tmpl
+++ b/Documentation/DocBook/gpu.tmpl
@@ -1816,7 +1816,7 @@ void intel_crt_init(struct drm_device *dev)
Description/Restrictions


-   DRM
+   DRM
Generic
“rotation”
BITMASK
@@ -2068,7 +2068,7 @@ void intel_crt_init(struct drm_device *dev)
property to suggest an Y offset for a connector


-   Optional
+   Optional
“scaling mode”
ENUM
{ "None", "Full", "Center", "Full aspect" }
@@ -2092,6 +2092,61 @@ void intel_crt_init(struct drm_device *dev)
TBD


+   “DEGAMMA_LUT”
+   BLOB
+   0
+   CRTC
+   DRM property to set the degamma lookup table
+   (LUT) mapping pixel data from the framebuffer before it is
+   given to the transformation matrix. The data is an interpreted
+   as an array of struct drm_color_lut elements. Hardware might
+   choose not to use the full precision of the LUT elements nor
+   use all the elements of the LUT (for example the hardware
+   might choose to interpolate between LUT[0] and LUT[4]). 
+   
+   
+   “DEGAMMA_LUT_SIZE”
+   RANGE | IMMUTABLE
+   Min=0, Max=UINT_MAX
+   CRTC
+   DRM property to gives the size of the lookup
+   table to be set on the DEGAMMA_LUT property (the size depends
+   on the underlying hardware).
+   
+   
+   “CTM”
+   BLOB
+   0
+   CRTC
+   DRM property to set the current
+   transformation matrix (CTM) apply to pixel data after the
+   lookup through the degamma LUT and before the lookup through
+   the gamma LUT. The data is an interpreted as a struct
+   drm_color_ctm.
+   
+   
+   “GAMMA_LUT”
+   BLOB
+   0
+   CRTC
+   DRM property to set the gamma lookup table
+   (LUT) mapping pixel data after to the transformation matrix to
+   data sent to the connector. The data is an interpreted as an
+   array of struct drm_color_lut elements. Hardware might choose
+   not to use the full precision of the LUT elements nor use all
+   the elements of the LUT (for example the hardware might choose
+   to interpolate between LUT[0] and LUT[4]).
+   
+   
+   “GAMMA_LUT_SIZE”
+   RANGE | IMMUTABLE
+   Min=0, Max=UINT_MAX
+   CRTC
+   DRM property to gives the size of the lookup
+   table to be set on the GAMMA_LUT property (the size depends on
+   the underlying hardware).
+   
+   
i915
Generic
"Broadcast RGB"

[Intel-gfx] [PATCH 1/5] drm/i915: Extract out gamma table and CSC to their own file

[Lionel Landwerlin]

The moves a couple of functions programming the gamma LUT and CSC
units into their own file.

On generations prior to Haswell there is only a gamma LUT. From
haswell on there is also a new enhanced color correction unit that
isn't used yet. This is why we need to set the GAMMA_MODE register,
either we're using the legacy 8bits LUT or enhanced LUTs (of 10 or
12bits).

The CSC unit is only available from Haswell on.

We also need to make a special case for CherryView which is recognized
as a gen 8 but doesn't have the same enhanced color correction unit
from Haswell on.

v2: Fix access to GAMMA_MODE register on older generations than
Haswell (from Matt Roper's comments)

Signed-off-by: Lionel Landwerlin 
Reviewed-by: Matt Roper 
---
 drivers/gpu/drm/i915/Makefile|   1 +
 drivers/gpu/drm/i915/i915_drv.h  |   2 +
 drivers/gpu/drm/i915/intel_color.c   | 190 +++
 drivers/gpu/drm/i915/intel_display.c | 163 +++---
 drivers/gpu/drm/i915/intel_drv.h |  10 ++
 5 files changed, 215 insertions(+), 151 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_color.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 0851de07..0516300 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -55,6 +55,7 @@ i915-y += intel_audio.o \
  intel_atomic.o \
  intel_atomic_plane.o \
  intel_bios.o \
+ intel_color.o \
  intel_display.o \
  intel_fbc.o \
  intel_fifo_underrun.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6644c2e..6634c09 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -659,6 +659,8 @@ struct drm_i915_display_funcs {
/* render clock increase/decrease */
/* display clock increase/decrease */
/* pll clock increase/decrease */
+
+   void (*load_luts)(struct drm_crtc *crtc);
 };
 
 enum forcewake_domain_id {
diff --git a/drivers/gpu/drm/i915/intel_color.c 
b/drivers/gpu/drm/i915/intel_color.c
new file mode 100644
index 000..5e0b997
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -0,0 +1,190 @@
+/*
+ * 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 "intel_drv.h"
+
+/*
+ * Set up the pipe CSC unit.
+ *
+ * Currently only full range RGB to limited range RGB conversion
+ * is supported, but eventually this should handle various
+ * RGB<->YCbCr scenarios as well.
+ */
+static void i9xx_load_csc_matrix(struct drm_crtc *crtc)
+{
+   struct drm_device *dev = crtc->dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   int pipe = intel_crtc->pipe;
+   uint16_t coeff = 0x7800; /* 1.0 */
+
+   /*
+* TODO: Check what kind of values actually come out of the pipe
+* with these coeff/postoff values and adjust to get the best
+* accuracy. Perhaps we even need to take the bpc value into
+* consideration.
+*/
+
+   if (intel_crtc->config->limited_color_range)
+   coeff = ((235 - 16) * (1 << 12) / 255) & 0xff8; /* 0.xxx... */
+
+   I915_WRITE(PIPE_CSC_COEFF_RY_GY(pipe), coeff << 16);
+   I915_WRITE(PIPE_CSC_COEFF_BY(pipe), 0);
+
+   I915_WRITE(PIPE_CSC_COEFF_RU_GU(pipe), coeff);
+   I915_WRITE(PIPE_CSC_COEFF_BU(pipe), 0);
+
+   I915_WRITE(PIPE_CSC_COEFF_RV_GV(pipe), 0);
+   I915_WRITE(PIPE_CSC_COEFF_BV(pipe), coeff << 16);
+
+   I915_WRITE(PIPE_CSC_PREOFF_HI(pipe), 0);
+   I915_WRITE(PIPE_CSC_PREOFF_ME(pipe), 0);
+   I915_WRITE(PIPE_CSC_PREOFF_LO(pipe), 0);
+
+   if (INTEL_INFO(dev)->gen > 6) {
+   uint16_t postoff = 0;
+
+   if 

Re: [Intel-gfx] [PATCH] drm/i915: Use SWF06 to figure out max cdclk for BDW

[Ville Syrjälä]

On Tue, Feb 23, 2016 at 06:40:37PM +0530, Thulasimani, Sivakumar wrote:
> 
> 
> On 2/23/2016 4:35 PM, Ville Syrjälä wrote:
> > On Tue, Feb 23, 2016 at 04:22:01PM +0530, Thulasimani, Sivakumar wrote:
> >>
> >> On 2/16/2016 3:35 PM, Ville Syrjälä wrote:
> >>> On Tue, Feb 16, 2016 at 07:13:05AM +0530, Thulasimani, Sivakumar wrote:
>  On 2/12/2016 8:36 PM, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> >
> > Bspec tells us that we can allow cdclk up to 540Mhz on BDW ULX, or
> > up to 675 MHz on ULT, bu only if extra cooling is provided. There
> > don't seem to be any strap or VBT bits to tells us this however.
> >
> > But I did spot something potentially relevant in
> > VBIOS_GOP_Driver_SWF_Registers.pdf. Apparently VBIOS/GOP can pass
> > the max cdclk frequeny in SWF06 to the driver. Let's assume the firmware
> > knows what its doing and trust the max cdclk in SWF06 if it's higher
> > than the basic limit specified in Bspec. To avoid regressing anything
> > let's ignore SWF06 if it indicates a lower limit than Bspec.
> >
> > Cc: Clint Taylor 
> > Cc: "Thulasimani, Sivakumar" 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >
> > I'm not at all sure if this is the right way to go about it. Sivakumar,
> > since you seem to have some ideas on this maybe you can have a look.
> > I'm not aware of any complaints so far that people can't get the cdclk
> > as high is they should on specific machines, so not sure if this is 
> > really
> > even needed.
> >
> > The other open question is what we should do if the VBIOS limit is
> > lower than what we'd expect based on BSpec. Should we still trust it?
> > Sadly we can't verify the SWF06 cdclk value in any way since it
> > only has two bits and we have four possible cdclk values.
>  The value stored in SWF06 is the CD Clock VBIOS/GOP sees during boot. so
>  it just backs up the CD Clock before it optimizes for the available LFP.
>  if we
>  are trusting for higher value we should trust it for lower value too.
>  The OEM might have did this to either reduce max resolution for cheaper
>  products or might have removed some cooling mechanisms for thinner
>  designs since we cannot say which of the reasons we should trust the
>  lower value too.
> 
>  now comes to tough part :(, this SWF06 is saved by VBIOS/GOP driver
>  from intel alone(it is not programmed from VBT),
>  since GOP driver can be implemented by anyone and
>  if anyone implements their own GOP driver we cannot be sure if the
>  value is valid or not. please check if we can check for "Intel GOP 
>  driver".
>  And if "Intel GOP driver" was used during boot, we can trust the value
>  100%.  i am not sure how this can be done, so i would recommend
>  trusting the values with clear debug messages as done below already.
> >>> We definitely need a way to validate the register value before we trust
> >>> it for lower values. I suppose we might be able to look at bits 31:16
> >>> since those should store the current cdclk "decimal" value. If that part
> >>> looks reasonable, we might be able to trust the "max cdclk" bits as well.
> >> it seems the bits 31:16 are used only by VBIOS and not GOP, so that wont
> >> help.
> >> we need to come up with some other method to confirm the value or verify
> >> if intel gop is loaded. i will get back if i can find such a mechanism.
> > Oh, that's unfortunate. IIRC we use some other SWF register to check if
> > something already initialized things in the cdclk sanitation path.
> > Not sure if the same could be used here.
> i am not aware of any other SWF register used for cdclk related flow so 
> cant help there.

I think the register was more of a canary and not directly related to
cdclk. And it was... SWF18. Hmm. Based on the spec that would indicate
some kind of initial pipe->connector mapping. So if there are no
displays connected, I suppose it might end up showing nothing either.
So yeah, probably not suitable for this stuff after all :(

> had a discussion with local folks and it seems like  there is
> no easy way out atleast for BDW.
> 
> SKL register using literal values is helpful in
> verifying against available set.
> 
> my best guess would be to handle it for BDW is as follows
> if BIT0:1 == 0 && current_cdclk != 450MHz
>we are not in intel GOP driver so take the current clock as max
> if BIT0:1 == 0 && current_cdclk == 450MHz
>  cant say which GOP driver was used, so limit to current clock 
> as max
> if BIT0:1 != 0
> probability of some other component setting these two bits is 
> very low :)
> so assume that we are in intel gop driver and trust the value.
>  we have checks to limit clock for the SKU so 

Re: [Intel-gfx] [PATCH v2] drm/i915: Avoid selecting unavailable BSD2 ring

[Chris Wilson]

On Tue, Feb 23, 2016 at 01:31:17PM +, Tvrtko Ursulin wrote:
> 
> On 23/02/16 13:06, Gabriel Feceoru wrote:
> > 
> > 
> > On 23.02.2016 13:05, Tvrtko Ursulin wrote:
> >>
> >> Hi,
> >>
> >> On 23/02/16 10:52, Gabriel Feceoru wrote:
> >>> Return error when I915_EXEC_BSD_RING2 flag is set but BSD2 ring
> >>> is not available in the HW.
> >>
> >> What is the reasoning behind this? So far kernel was allowing userspace
> >> to select these bits and execute on the first engine. With this patch it
> >> would start failing potentially breaking userspace. Is it not too late
> >> to make such change?
> > 
> > I noticed some inconsistencies in igt with regards to bsd and bsd1.
> > For instance, if bsd2 is not available, gem_sync@basic-bsd1 is skipped, 
> > but it's skipped because of the 2nd check gem_has_bsd2 (see 
> > gem_require_ring). Surprisingly gem_has_ring() didn't complain about bsd1.
> > 
> > This fix will make gem_has_ring() return false.
> > 
> > I'm not aware about legacy/compatibility issue - if that's the case, 
> > please disregard this.
> 
> Hmmm.. Chris, what is the reasoning behind:
> 
> commit eaa03678b00179da89f194113c0740c033857c1c
> Author: Chris Wilson 
> Date:   Thu Jan 28 13:44:19 2016 +
> 
> lib: Hide BSD1/BSD2 rings on hardware without BSD2
> 
> The kernel happily lets us run on I915_EXEC_BSD2 even with such hardware
> existing. Sigh.
> 
> Signed-off-by: Chris Wilson 
> 
> diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
> index 9dfa9b2603ce..fa44080e5902 100644
> --- a/lib/ioctl_wrappers.c
> +++ b/lib/ioctl_wrappers.c
> @@ -1341,6 +1341,12 @@ static int gem_has_ring(int fd, int ring)
>  void gem_require_ring(int fd, int ring_id)
>  {
> igt_require(gem_has_ring(fd, ring_id));
> +
> +   /* silly ABI, the kernel thinks everyone who has BSD also has BSD2 */
> +   if ((ring_id & ~(3<<13)) == I915_EXEC_BSD) {
> +   if (ring_id & (3 << 13))
> +   igt_require(gem_has_bsd2(fd));
> +   }
>  }
>  
>  /* prime */
> 
> ABI was (and still is) that specifying BSD1 or BSD2 explicitly is
> silently ignored by the kernel when BSD2 is not preset, defaulting
> to BSD1.

Thereby pretending that BSD, BSD1, BSD2 exist.

> This patch makes tests requesting BSD1 skip when there is no BSD2
> which I think is wrong in any case.

BSD 1/2 selection only makes sense when we have multiple BSD rings.
Running tests on BSD default, BSD1 and BSD2 is pointless if they all
are equivalent. Using the BSD ping-pong when we have BSD1 and BSD2 is
questionable as the ping-pong nature is uncontrolled, but nevertheless
the code path needs to be tested.

> If we want to (and can) change the ABI it should only reject the
> non-existent ring and not limit the selection mechanism to
> hardware which has BSD2.

I disagree, we have a ring selection mechanism. If the extension doesn't
exist, trying to use it should be an error. The extension was not only
an ABI mistake but undesired (it is now defunct).
-Chris

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

[Intel-gfx] [PATCH] drm/i915/lrc: Only set RS ctx enable in ctx control reg if there is a RS

[Michel Thierry]

The driver should only set the "RS context enable" bit in the context
image if we plan to use the resource streamer.

Signed-off-by: Michel Thierry 
---
 drivers/gpu/drm/i915/intel_lrc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index e12fcab..c3779b9 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2382,7 +2382,8 @@ populate_lr_context(struct intel_context *ctx, struct 
drm_i915_gem_object *ctx_o
ASSIGN_CTX_REG(reg_state, CTX_CONTEXT_CONTROL, 
RING_CONTEXT_CONTROL(ring),
   _MASKED_BIT_ENABLE(CTX_CTRL_INHIBIT_SYN_CTX_SWITCH |
  CTX_CTRL_ENGINE_CTX_RESTORE_INHIBIT |
- CTX_CTRL_RS_CTX_ENABLE));
+ (HAS_RESOURCE_STREAMER(dev) ?
+   CTX_CTRL_RS_CTX_ENABLE : 0)));
ASSIGN_CTX_REG(reg_state, CTX_RING_HEAD, RING_HEAD(ring->mmio_base), 0);
ASSIGN_CTX_REG(reg_state, CTX_RING_TAIL, RING_TAIL(ring->mmio_base), 0);
/* Ring buffer start address is not known until the buffer is pinned.
-- 
2.7.1

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

Re: [Intel-gfx] [PATCH v2] drm/i915: Avoid selecting unavailable BSD2 ring

[Tvrtko Ursulin]

On 23/02/16 13:06, Gabriel Feceoru wrote:
> 
> 
> On 23.02.2016 13:05, Tvrtko Ursulin wrote:
>>
>> Hi,
>>
>> On 23/02/16 10:52, Gabriel Feceoru wrote:
>>> Return error when I915_EXEC_BSD_RING2 flag is set but BSD2 ring
>>> is not available in the HW.
>>
>> What is the reasoning behind this? So far kernel was allowing userspace
>> to select these bits and execute on the first engine. With this patch it
>> would start failing potentially breaking userspace. Is it not too late
>> to make such change?
> 
> I noticed some inconsistencies in igt with regards to bsd and bsd1.
> For instance, if bsd2 is not available, gem_sync@basic-bsd1 is skipped, 
> but it's skipped because of the 2nd check gem_has_bsd2 (see 
> gem_require_ring). Surprisingly gem_has_ring() didn't complain about bsd1.
> 
> This fix will make gem_has_ring() return false.
> 
> I'm not aware about legacy/compatibility issue - if that's the case, 
> please disregard this.

Hmmm.. Chris, what is the reasoning behind:

commit eaa03678b00179da89f194113c0740c033857c1c
Author: Chris Wilson 
Date:   Thu Jan 28 13:44:19 2016 +

lib: Hide BSD1/BSD2 rings on hardware without BSD2

The kernel happily lets us run on I915_EXEC_BSD2 even with such hardware
existing. Sigh.

Signed-off-by: Chris Wilson 

diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
index 9dfa9b2603ce..fa44080e5902 100644
--- a/lib/ioctl_wrappers.c
+++ b/lib/ioctl_wrappers.c
@@ -1341,6 +1341,12 @@ static int gem_has_ring(int fd, int ring)
 void gem_require_ring(int fd, int ring_id)
 {
igt_require(gem_has_ring(fd, ring_id));
+
+   /* silly ABI, the kernel thinks everyone who has BSD also has BSD2 */
+   if ((ring_id & ~(3<<13)) == I915_EXEC_BSD) {
+   if (ring_id & (3 << 13))
+   igt_require(gem_has_bsd2(fd));
+   }
 }
 
 /* prime */

ABI was (and still is) that specifying BSD1 or BSD2 explicitly is
silently ignored by the kernel when BSD2 is not preset, defaulting
to BSD1.

This patch makes tests requesting BSD1 skip when there is no BSD2
which I think is wrong in any case.

If we want to (and can) change the ABI it should only reject the
non-existent ring and not limit the selection mechanism to
hardware which has BSD2.

Regards,

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

Re: [Intel-gfx] [RFCv2 03/14] drm/i915: Introduce host graphics memory/fence partition for GVT-g

[Joonas Lahtinen]

On ti, 2016-02-23 at 15:16 +0200, Joonas Lahtinen wrote:
> > 
> > On to, 2016-02-18 at 19:42 +0800, Zhi Wang wrote:
> > From: Bing Niu 
> > 
> > This patch introduces host graphics memory/fence partition when GVT-g
> > is enabled.
> > 
> > Under GVT-g, i915 host driver only owned limited graphics resources,
> > others are managed by GVT-g resource allocator and kept for other vGPUs.
> > 
> > v2:
> > - Address all coding-style comments from Joonas previously.
> > - Fix errors and warnning reported by checkpatch.pl. (Joonas)
> > - Move the graphs into the header files. (Daniel)
> > 
> > Signed-off-by: Bing Niu 
> > Signed-off-by: Zhi Wang 
> > ---
> >  drivers/gpu/drm/i915/gvt/gvt.c  |  4 
> >  drivers/gpu/drm/i915/gvt/params.c   | 12 
> >  drivers/gpu/drm/i915/gvt/params.h   |  3 +++
> >  drivers/gpu/drm/i915/i915_drv.h | 35 
> > +++
> >  drivers/gpu/drm/i915/i915_gem.c |  4 +++-
> >  drivers/gpu/drm/i915/i915_gem_gtt.c |  4 ++--
> >  drivers/gpu/drm/i915/i915_vgpu.c| 21 +
> >  7 files changed, 76 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c
> > index 52cfa32..2099b7e 100644
> > --- a/drivers/gpu/drm/i915/gvt/gvt.c
> > +++ b/drivers/gpu/drm/i915/gvt/gvt.c
> > @@ -348,6 +348,10 @@ void *gvt_create_pgt_device(struct drm_i915_private 
> > *dev_priv)
> >     goto err;
> >     }
> >  
> > +   dev_priv->gvt.host_fence_sz = gvt.host_fence_sz;
> > +   dev_priv->gvt.host_low_gm_sz_in_mb = gvt.host_low_gm_sz;
> > +   dev_priv->gvt.host_high_gm_sz_in_mb = gvt.host_high_gm_sz;
> 
> I'm thinking, could we expose the pgt_device struct (at least
> partially, and then have a PIMPL pattern), to avoid this kind of
> duplication of declarations and unnecessary copies between i915 and
> i915_gvt modules?
> 
> It's little rough that the gvt driver writes to i915_private struct.
> I'd rather see that gvt.host_fence_sz and other variables get sanitized
> and then written to pgt_device (maybe the public part would be
> i915_pgt_device) and used by gvt and i915 code.
> 

Also, using memparse to handle all kernel memory size parameters is a
good idea (see parse_highmem() or related function). That is what users
expect.

> Was this ever considered?
> 



> > diff --git a/drivers/gpu/drm/i915/i915_vgpu.c 
> > b/drivers/gpu/drm/i915/i915_vgpu.c
> > index dea7429..7be1435 100644
> > --- a/drivers/gpu/drm/i915/i915_vgpu.c
> > +++ b/drivers/gpu/drm/i915/i915_vgpu.c
> > @@ -188,10 +188,23 @@ int intel_vgt_balloon(struct drm_device *dev)
> >     unsigned long unmappable_base, unmappable_size, unmappable_end;
> >     int ret;
> >  
> > -   mappable_base = I915_READ(vgtif_reg(avail_rs.mappable_gmadr.base));
> > -   mappable_size = I915_READ(vgtif_reg(avail_rs.mappable_gmadr.size));
> > -   unmappable_base = I915_READ(vgtif_reg(avail_rs.nonmappable_gmadr.base));
> > -   unmappable_size = I915_READ(vgtif_reg(avail_rs.nonmappable_gmadr.size));
> > +   if (intel_gvt_active(dev)) {
> > +   mappable_base = 0;
> > +   mappable_size = dev_priv->gvt.host_low_gm_sz_in_mb << 20;
> > +   unmappable_base = dev_priv->gtt.mappable_end;
> > +   unmappable_size = dev_priv->gvt.host_high_gm_sz_in_mb << 20;

This could be avoided too.

> > +   } else if (intel_vgpu_active(dev)) {
> > +   mappable_base = I915_READ(
> > +   vgtif_reg(avail_rs.mappable_gmadr.base));
> > +   mappable_size = I915_READ(
> > +   vgtif_reg(avail_rs.mappable_gmadr.size));
> > +   unmappable_base = I915_READ(
> > +   vgtif_reg(avail_rs.nonmappable_gmadr.base));
> > +   unmappable_size = I915_READ(
> > +   vgtif_reg(avail_rs.nonmappable_gmadr.size));
> > +   } else {
> > +   return -ENODEV;
> > +   }
> >  
> >     mappable_end = mappable_base + mappable_size;
> >     unmappable_end = unmappable_base + unmappable_size;
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFCv2 03/14] drm/i915: Introduce host graphics memory/fence partition for GVT-g

[Zhi Wang]

On 02/23/16 21:16, Joonas Lahtinen wrote:

On to, 2016-02-18 at 19:42 +0800, Zhi Wang wrote:

From: Bing Niu 

This patch introduces host graphics memory/fence partition when GVT-g
is enabled.

Under GVT-g, i915 host driver only owned limited graphics resources,
others are managed by GVT-g resource allocator and kept for other vGPUs.

v2:
- Address all coding-style comments from Joonas previously.
- Fix errors and warnning reported by checkpatch.pl. (Joonas)
- Move the graphs into the header files. (Daniel)

Signed-off-by: Bing Niu 
Signed-off-by: Zhi Wang 
---
  drivers/gpu/drm/i915/gvt/gvt.c  |  4 
  drivers/gpu/drm/i915/gvt/params.c   | 12 
  drivers/gpu/drm/i915/gvt/params.h   |  3 +++
  drivers/gpu/drm/i915/i915_drv.h | 35 +++
  drivers/gpu/drm/i915/i915_gem.c |  4 +++-
  drivers/gpu/drm/i915/i915_gem_gtt.c |  4 ++--
  drivers/gpu/drm/i915/i915_vgpu.c| 21 +
  7 files changed, 76 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c
index 52cfa32..2099b7e 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.c
+++ b/drivers/gpu/drm/i915/gvt/gvt.c
@@ -348,6 +348,10 @@ void *gvt_create_pgt_device(struct drm_i915_private 
*dev_priv)
goto err;
}

+   dev_priv->gvt.host_fence_sz = gvt.host_fence_sz;
+   dev_priv->gvt.host_low_gm_sz_in_mb = gvt.host_low_gm_sz;
+   dev_priv->gvt.host_high_gm_sz_in_mb = gvt.host_high_gm_sz;


I'm thinking, could we expose the pgt_device struct (at least
partially, and then have a PIMPL pattern), to avoid this kind of
duplication of declarations and unnecessary copies between i915 and
i915_gvt modules?

It's little rough that the gvt driver writes to i915_private struct.
I'd rather see that gvt.host_fence_sz and other variables get sanitized
and then written to pgt_device (maybe the public part would be
i915_pgt_device) and used by gvt and i915 code.

Was this ever considered?

The previous version do something similar like that, both i915 and gvt 
reads GVT module kernel parameter but considered that GVT modules could 
be configured as "n" in kernel configuration, probably we should let 
i915 to store this information and GVT to configure it if GVT is active?

+
gvt_dbg_core("pgt device creation done, id %d", pdev->id);

return pdev;
diff --git a/drivers/gpu/drm/i915/gvt/params.c 
b/drivers/gpu/drm/i915/gvt/params.c
index d381d17..75195fd 100644
--- a/drivers/gpu/drm/i915/gvt/params.c
+++ b/drivers/gpu/drm/i915/gvt/params.c
@@ -26,7 +26,19 @@
  struct gvt_kernel_params gvt = {
.enable = false,
.debug = 0,
+   .host_low_gm_sz = 96,   /* in MB */
+   .host_high_gm_sz = 384, /* in MB */
+   .host_fence_sz = 4,
  };

  module_param_named(gvt_enable, gvt.enable, bool, 0600);
  MODULE_PARM_DESC(gvt_enable, "Enable Intel GVT-g host support");
+
+module_param_named(gvt_host_low_gm_sz, gvt.host_low_gm_sz, int, 0600);
+MODULE_PARM_DESC(gvt_host_low_gm_sz, "Amount of aperture size of host (in 
MB)");


As i915_gvt will be the host module, "gvt_host" can be removed so the
module parameters become;

i915_gvt.low_gm_sz instead of i915_gvt.gvt_host_low_gm_sz

Also should these be _unsafe parameters because I bet they can make the
machine go crazy if wrong?


Yes, the params need to be checked, indeed.

+
+module_param_named(gvt_host_high_gm_sz, gvt.host_high_gm_sz, int, 0600);
+MODULE_PARM_DESC(gvt_host_high_gm_sz, "Amount of high memory size of host (in 
MB)");
+
+module_param_named(gvt_host_fence_sz, gvt.host_fence_sz, int, 0600);
+MODULE_PARM_DESC(gvt_host_fence_sz, "Amount of fence size of host (in MB)");
diff --git a/drivers/gpu/drm/i915/gvt/params.h 
b/drivers/gpu/drm/i915/gvt/params.h
index d2955b9..f4e9356 100644
--- a/drivers/gpu/drm/i915/gvt/params.h
+++ b/drivers/gpu/drm/i915/gvt/params.h
@@ -27,6 +27,9 @@
  struct gvt_kernel_params {
bool enable;
int debug;
+   int host_low_gm_sz;
+   int host_high_gm_sz;
+   int host_fence_sz;
  };

  extern struct gvt_kernel_params gvt;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2f897c3..1fd5575 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1705,8 +1705,43 @@ struct i915_workarounds {
u32 hw_whitelist_count[I915_NUM_RINGS];
  };

+/*
+ * Under GVT-g, i915 host driver only owned limited graphics resources,
+ * others are managed by GVT-g resource allocator and kept for other vGPUs.
+ *
+ * For graphics memory space partition, a typical layout looks like:
+ *
+ * +---+---+--+---+
+ * |* Host |   *GVT-g Resource |* Host|   *GVT-g Resource |
+ * | Owned |   Allocator Managed   | Owned|   Allocator Managed   |
+ * |   |   |  |   |
+ * 

Re: [Intel-gfx] [RFCv2 03/14] drm/i915: Introduce host graphics memory/fence partition for GVT-g

[Joonas Lahtinen]

On to, 2016-02-18 at 19:42 +0800, Zhi Wang wrote:
> From: Bing Niu 
> 
> This patch introduces host graphics memory/fence partition when GVT-g
> is enabled.
> 
> Under GVT-g, i915 host driver only owned limited graphics resources,
> others are managed by GVT-g resource allocator and kept for other vGPUs.
> 
> v2:
> - Address all coding-style comments from Joonas previously.
> - Fix errors and warnning reported by checkpatch.pl. (Joonas)
> - Move the graphs into the header files. (Daniel)
> 
> Signed-off-by: Bing Niu 
> Signed-off-by: Zhi Wang 
> ---
>  drivers/gpu/drm/i915/gvt/gvt.c  |  4 
>  drivers/gpu/drm/i915/gvt/params.c   | 12 
>  drivers/gpu/drm/i915/gvt/params.h   |  3 +++
>  drivers/gpu/drm/i915/i915_drv.h | 35 +++
>  drivers/gpu/drm/i915/i915_gem.c |  4 +++-
>  drivers/gpu/drm/i915/i915_gem_gtt.c |  4 ++--
>  drivers/gpu/drm/i915/i915_vgpu.c| 21 +
>  7 files changed, 76 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c
> index 52cfa32..2099b7e 100644
> --- a/drivers/gpu/drm/i915/gvt/gvt.c
> +++ b/drivers/gpu/drm/i915/gvt/gvt.c
> @@ -348,6 +348,10 @@ void *gvt_create_pgt_device(struct drm_i915_private 
> *dev_priv)
>   goto err;
>   }
>  
> + dev_priv->gvt.host_fence_sz = gvt.host_fence_sz;
> + dev_priv->gvt.host_low_gm_sz_in_mb = gvt.host_low_gm_sz;
> + dev_priv->gvt.host_high_gm_sz_in_mb = gvt.host_high_gm_sz;

I'm thinking, could we expose the pgt_device struct (at least
partially, and then have a PIMPL pattern), to avoid this kind of
duplication of declarations and unnecessary copies between i915 and
i915_gvt modules?

It's little rough that the gvt driver writes to i915_private struct.
I'd rather see that gvt.host_fence_sz and other variables get sanitized
and then written to pgt_device (maybe the public part would be
i915_pgt_device) and used by gvt and i915 code.

Was this ever considered?

> +
>   gvt_dbg_core("pgt device creation done, id %d", pdev->id);
>  
>   return pdev;
> diff --git a/drivers/gpu/drm/i915/gvt/params.c 
> b/drivers/gpu/drm/i915/gvt/params.c
> index d381d17..75195fd 100644
> --- a/drivers/gpu/drm/i915/gvt/params.c
> +++ b/drivers/gpu/drm/i915/gvt/params.c
> @@ -26,7 +26,19 @@
>  struct gvt_kernel_params gvt = {
>   .enable = false,
>   .debug = 0,
> + .host_low_gm_sz = 96,   /* in MB */
> + .host_high_gm_sz = 384, /* in MB */
> + .host_fence_sz = 4,
>  };
>  
>  module_param_named(gvt_enable, gvt.enable, bool, 0600);
>  MODULE_PARM_DESC(gvt_enable, "Enable Intel GVT-g host support");
> +
> +module_param_named(gvt_host_low_gm_sz, gvt.host_low_gm_sz, int, 0600);
> +MODULE_PARM_DESC(gvt_host_low_gm_sz, "Amount of aperture size of host (in 
> MB)");

As i915_gvt will be the host module, "gvt_host" can be removed so the
module parameters become;

i915_gvt.low_gm_sz instead of i915_gvt.gvt_host_low_gm_sz

Also should these be _unsafe parameters because I bet they can make the
machine go crazy if wrong?

> +
> +module_param_named(gvt_host_high_gm_sz, gvt.host_high_gm_sz, int, 0600);
> +MODULE_PARM_DESC(gvt_host_high_gm_sz, "Amount of high memory size of host 
> (in MB)");
> +
> +module_param_named(gvt_host_fence_sz, gvt.host_fence_sz, int, 0600);
> +MODULE_PARM_DESC(gvt_host_fence_sz, "Amount of fence size of host (in MB)");
> diff --git a/drivers/gpu/drm/i915/gvt/params.h 
> b/drivers/gpu/drm/i915/gvt/params.h
> index d2955b9..f4e9356 100644
> --- a/drivers/gpu/drm/i915/gvt/params.h
> +++ b/drivers/gpu/drm/i915/gvt/params.h
> @@ -27,6 +27,9 @@
>  struct gvt_kernel_params {
>   bool enable;
>   int debug;
> + int host_low_gm_sz;
> + int host_high_gm_sz;
> + int host_fence_sz;
>  };
>  
>  extern struct gvt_kernel_params gvt;
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 2f897c3..1fd5575 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1705,8 +1705,43 @@ struct i915_workarounds {
>   u32 hw_whitelist_count[I915_NUM_RINGS];
>  };
>  
> +/*
> + * Under GVT-g, i915 host driver only owned limited graphics resources,
> + * others are managed by GVT-g resource allocator and kept for other vGPUs.
> + *
> + * For graphics memory space partition, a typical layout looks like:
> + *
> + * +---+---+--+---+
> + * |* Host |   *GVT-g Resource |* Host|   *GVT-g Resource |
> + * | Owned |   Allocator Managed   | Owned|   Allocator Managed   |
> + * |   |   |  |   |
> + * +---+---+--+---+---+
> + * |   |   |   |   |  |   |   |   |
> + * | i915  | vm 1  | vm 2  | vm 3  | i915 | vm 1  | vm 2  | vm 3  |
> + * |   |   |   |   |  |

Re: [Intel-gfx] [PATCH] drm/i915: Use SWF06 to figure out max cdclk for BDW

[Thulasimani, Sivakumar]

On 2/23/2016 4:35 PM, Ville Syrjälä wrote:

On Tue, Feb 23, 2016 at 04:22:01PM +0530, Thulasimani, Sivakumar wrote:


On 2/16/2016 3:35 PM, Ville Syrjälä wrote:

On Tue, Feb 16, 2016 at 07:13:05AM +0530, Thulasimani, Sivakumar wrote:

On 2/12/2016 8:36 PM, ville.syrj...@linux.intel.com wrote:

From: Ville Syrjälä 

Bspec tells us that we can allow cdclk up to 540Mhz on BDW ULX, or
up to 675 MHz on ULT, bu only if extra cooling is provided. There
don't seem to be any strap or VBT bits to tells us this however.

But I did spot something potentially relevant in
VBIOS_GOP_Driver_SWF_Registers.pdf. Apparently VBIOS/GOP can pass
the max cdclk frequeny in SWF06 to the driver. Let's assume the firmware
knows what its doing and trust the max cdclk in SWF06 if it's higher
than the basic limit specified in Bspec. To avoid regressing anything
let's ignore SWF06 if it indicates a lower limit than Bspec.

Cc: Clint Taylor 
Cc: "Thulasimani, Sivakumar" 
Signed-off-by: Ville Syrjälä 
---

I'm not at all sure if this is the right way to go about it. Sivakumar,
since you seem to have some ideas on this maybe you can have a look.
I'm not aware of any complaints so far that people can't get the cdclk
as high is they should on specific machines, so not sure if this is really
even needed.

The other open question is what we should do if the VBIOS limit is
lower than what we'd expect based on BSpec. Should we still trust it?
Sadly we can't verify the SWF06 cdclk value in any way since it
only has two bits and we have four possible cdclk values.

The value stored in SWF06 is the CD Clock VBIOS/GOP sees during boot. so
it just backs up the CD Clock before it optimizes for the available LFP.
if we
are trusting for higher value we should trust it for lower value too.
The OEM might have did this to either reduce max resolution for cheaper
products or might have removed some cooling mechanisms for thinner
designs since we cannot say which of the reasons we should trust the
lower value too.

now comes to tough part :(, this SWF06 is saved by VBIOS/GOP driver
from intel alone(it is not programmed from VBT),
since GOP driver can be implemented by anyone and
if anyone implements their own GOP driver we cannot be sure if the
value is valid or not. please check if we can check for "Intel GOP driver".
And if "Intel GOP driver" was used during boot, we can trust the value
100%.  i am not sure how this can be done, so i would recommend
trusting the values with clear debug messages as done below already.

We definitely need a way to validate the register value before we trust
it for lower values. I suppose we might be able to look at bits 31:16
since those should store the current cdclk "decimal" value. If that part
looks reasonable, we might be able to trust the "max cdclk" bits as well.

it seems the bits 31:16 are used only by VBIOS and not GOP, so that wont
help.
we need to come up with some other method to confirm the value or verify
if intel gop is loaded. i will get back if i can find such a mechanism.

Oh, that's unfortunate. IIRC we use some other SWF register to check if
something already initialized things in the cdclk sanitation path.
Not sure if the same could be used here.
i am not aware of any other SWF register used for cdclk related flow so 
cant help there.

had a discussion with local folks and it seems like  there is
no easy way out atleast for BDW.

SKL register using literal values is helpful in
verifying against available set.

my best guess would be to handle it for BDW is as follows
if BIT0:1 == 0 && current_cdclk != 450MHz
  we are not in intel GOP driver so take the current clock as max
if BIT0:1 == 0 && current_cdclk == 450MHz
cant say which GOP driver was used, so limit to current clock 
as max

if BIT0:1 != 0
   probability of some other component setting these two bits is 
very low :)

   so assume that we are in intel gop driver and trust the value.
we have checks to limit clock for the SKU so it should not be a 
problem

   to trust the value in register.


regards,
Sivakumar

As mentioned in another thread, this needs to be done for SKL too.
i dont have a SKL system so if no one else can make a patch for it
i will have to share an untested patch for it :).

For SKL it seems a bit easier, since it apparently just stores the max
cdclk in 10.1 decimal fixed point in bits 10:0. So invalid/uninitialized
values would be easier to spot.

Hmm. 11 bits and 10.1 fixed point format, I wonder if it's really
decimal and not binary fixed point...

it uses the same value programmed in CDCLK_CTL register.
i.e 01 0011 0011 1b= 308.57MHz

OK, so binary fixed point. Maybe I should file a bug against bspec to
remove this confusing "decimal" naming scheme from the cdclk stuff...


regards,
Sivakumar

drivers/gpu/drm/i915/intel_display.c | 60 

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/gen9: Set value of Indirect Context Offset based on gen version (rev4)

[Michel Thierry]

On Tue, Feb 23, 2016 at 11:21 AM, Patchwork 
 wrote:

== Series Details ==

Series: drm/i915/gen9: Set value of Indirect Context Offset based on gen
version (rev4)
URL   : https://patchwork.freedesktop.org/series/3629/
State : warning

== Summary ==

Series 3629v4 drm/i915/gen9: Set value of Indirect Context Offset based
on gen version
http://patchwork.freedesktop.org/api/1.0/series/3629/revisions/4/mbox/

Test gem_cs_prefetch:
 Subgroup basic-default:
 incomplete -> PASS   (ilk-hp8440p)
Test kms_force_connector_basic:
 Subgroup force-edid:
 skip   -> PASS   (snb-x220t)
 Subgroup force-load-detect:
 dmesg-fail -> FAIL   (snb-x220t)
 dmesg-fail -> FAIL   (snb-dellxps)
 fail   -> DMESG-FAIL (ilk-hp8440p)


Unrelated to this patch, snd and ilk don't have execlists.

Looks like it has been like this for a while: 
/archive/results/CI_IGT_test/igt@kms_force_connector_ba...@force-load-detect.html


Also, this subtest is quite recent, 
https://cgit.freedesktop.org/xorg/app/intel-gpu-tools/commit/?id=7670e286f5043d04af0cd1e6df1f092b5bcaf09e



Test kms_pipe_crc_basic:
 Subgroup suspend-read-crc-pipe-b:
 dmesg-warn -> PASS   (skl-i5k-2) UNSTABLE
 pass   -> DMESG-WARN (ilk-hp8440p)


Got this warning in ilk,
[  591.239261] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* 
CPU pipe B FIFO underrun




 Subgroup suspend-read-crc-pipe-c:
 pass   -> DMESG-WARN (skl-i5k-2) UNSTABLE
 pass   -> DMESG-WARN (bsw-nuc-2)


Same as: https://bugs.freedesktop.org/show_bug.cgi?id=93294 (cpu_hotplug 
lockdep fail).



Test pm_rpm:
 Subgroup basic-pci-d3-state:
 pass   -> DMESG-WARN (bsw-nuc-2)


Already reported in https://bugs.freedesktop.org/show_bug.cgi?id=94163



bdw-nuci7total:165  pass:154  dwarn:0   dfail:0   fail:0   skip:11
bdw-ultratotal:168  pass:154  dwarn:0   dfail:0   fail:0   skip:14
bsw-nuc-2total:168  pass:135  dwarn:2   dfail:0   fail:1   skip:30
byt-nuc  total:168  pass:142  dwarn:1   dfail:0   fail:0   skip:25
hsw-gt2  total:168  pass:157  dwarn:0   dfail:1   fail:0   skip:10
ilk-hp8440p  total:168  pass:117  dwarn:1   dfail:1   fail:0   skip:49
ivb-t430stotal:168  pass:153  dwarn:0   dfail:0   fail:1   skip:14
skl-i5k-2total:168  pass:151  dwarn:1   dfail:0   fail:0   skip:16
snb-dellxps  total:168  pass:145  dwarn:0   dfail:0   fail:1   skip:22
snb-x220ttotal:168  pass:145  dwarn:0   dfail:0   fail:2   skip:21

Results at /archive/results/CI_IGT_test/Patchwork_1460/

08fc1b101049694778bff7559e1d05250d2e7072 drm-intel-nightly:
2016y-02m-22d-17h-30m-27s UTC integration manifest
644bbd41dad8857b829a3c627d951873592a7f63 drm/i915/gen9: Set value of
Indirect Context Offset based on gen version

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



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

Re: [Intel-gfx] [PATCH v2] drm/i915: Avoid selecting unavailable BSD2 ring

[Gabriel Feceoru]

On 23.02.2016 13:05, Tvrtko Ursulin wrote:


Hi,

On 23/02/16 10:52, Gabriel Feceoru wrote:

Return error when I915_EXEC_BSD_RING2 flag is set but BSD2 ring
is not available in the HW.


What is the reasoning behind this? So far kernel was allowing userspace
to select these bits and execute on the first engine. With this patch it
would start failing potentially breaking userspace. Is it not too late
to make such change?


I noticed some inconsistencies in igt with regards to bsd and bsd1.
For instance, if bsd2 is not available, gem_sync@basic-bsd1 is skipped, 
but it's skipped because of the 2nd check gem_has_bsd2 (see 
gem_require_ring). Surprisingly gem_has_ring() didn't complain about bsd1.


This fix will make gem_has_ring() return false.

I'm not aware about legacy/compatibility issue - if that's the case, 
please disregard this.


Regards,
Gabriel



Regards,

Tvrtko


v2: Reworked
Signed-off-by: Gabriel Feceoru 
---
  drivers/gpu/drm/i915/i915_gem_execbuffer.c | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 8fd00d2..9fbd023 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1394,6 +1394,13 @@ eb_select_ring(struct drm_i915_private *dev_priv,
  return -EINVAL;
  }

+if ((user_ring_id == I915_EXEC_BSD) && !HAS_BSD2(dev_priv) &&
+((args->flags & I915_EXEC_BSD_MASK) != 0)) {
+DRM_DEBUG("execbuf with bsd ring but with invalid "
+  "bsd dispatch flags: %d\n", (int)(args->flags));
+return -EINVAL;
+}
+
  if (user_ring_id == I915_EXEC_BSD && HAS_BSD2(dev_priv)) {
  unsigned int bsd_idx = args->flags & I915_EXEC_BSD_MASK;



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

Re: [Intel-gfx] [PATCH v4 2/3] drm/i915: refactor duplicate object vmap functions (reworked)

[Chris Wilson]

On Tue, Feb 23, 2016 at 12:25:29PM +, Tvrtko Ursulin wrote:
> 
> On 23/02/16 11:52, Chris Wilson wrote:
> >On Tue, Feb 23, 2016 at 11:38:02AM +, Chris Wilson wrote:
> >>Indeed, we would need a new notifier, pretty much for the sole use of
> >>32b. Grr, that will be a nuisance.
> >
> >Core changes:
> >
> >diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h
> >index d1f1d338af20..542a91c2785f 100644
> >--- a/include/linux/vmalloc.h
> >+++ b/include/linux/vmalloc.h
> >@@ -187,4 +187,8 @@ pcpu_free_vm_areas(struct vm_struct **vms, int nr_vms)
> >  #define VMALLOC_TOTAL 0UL
> >  #endif
> >
> >+struct notitifer_block;
> >+int register_vmap_notifier(struct notifier_block *nb);
> >+int unregister_vmap_notifier(struct notifier_block *nb);
> >+
> >  #endif /* _LINUX_VMALLOC_H */
> >diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> >index fb42a5bffe47..0735d82444f7 100644
> >--- a/mm/vmalloc.c
> >+++ b/mm/vmalloc.c
> >@@ -21,6 +21,7 @@
> >  #include 
> >  #include 
> >  #include 
> >+#include 
> >  #include 
> >  #include 
> >  #include 
> >@@ -344,6 +345,8 @@ static void __insert_vmap_area(struct vmap_area *va)
> >
> >  static void purge_vmap_area_lazy(void);
> >
> >+static BLOCKING_NOTIFIER_HEAD(vmap_notify_list);
> >+
> >  /*
> >   * Allocate a region of KVA of the specified size and alignment, within the
> >   * vstart and vend.
> >@@ -356,6 +359,7 @@ static struct vmap_area *alloc_vmap_area(unsigned long 
> >size,
> > struct vmap_area *va;
> > struct rb_node *n;
> > unsigned long addr;
> >+   unsigned long freed;
> > int purged = 0;
> > struct vmap_area *first;
> >
> >@@ -468,6 +472,12 @@ overflow:
> > purged = 1;
> > goto retry;
> > }
> >+   freed = 0;
> >+   blocking_notifier_call_chain(_notify_list, 0, );
> >+   if (freed > 0) {
> >+   purged = 0;
> >+   goto retry;
> >+   }
> > if (printk_ratelimit())
> > pr_warn("vmap allocation for size %lu failed: "
> > "use vmalloc= to increase size.\n", size);
> >@@ -475,6 +485,18 @@ overflow:
> > return ERR_PTR(-EBUSY);
> >  }
> >
> >+int register_vmap_notifier(struct notifier_block *nb)
> >+{
> >+   return blocking_notifier_chain_register(_notify_list, nb);
> >+}
> >+EXPORT_SYMBOL_GPL(register_vmap_notifier);
> >+
> >+int unregister_vmap_notifier(struct notifier_block *nb)
> >+{
> >+   return blocking_notifier_chain_unregister(_notify_list, nb);
> >+}
> >+EXPORT_SYMBOL_GPL(unregister_vmap_notifier);
> >+
> >  static void __free_vmap_area(struct vmap_area *va)
> >  {
> > BUG_ON(RB_EMPTY_NODE(>rb_node));
> >
> >
> >That doesn't look too horrendous. Names?
> 
> Downside is new deadlock opportunity so GEM callers to vmap would
> have to release the struct mutex.

No, the shrinker can steal the mutex for itself (or gives up). Callers
need to be sure that they pin their pages before doing any allocations
if they intend to use the pages afterwards. (i.e. we want to apply the
same rules for get_pages vs malloc to get_pages vs vmalloc).
 
> >register_oovmap_notifier
> >register_vmap_nospace_notifier?
> >register_vmap_purge_notifier?
> 
> register_vmap_shrinker ?
> 
> >And the 64k question, how to sell it?
> 
> Not sure, maybe with numbers showing that caching the vmapping helps
> us significantly?

Something along the lines of how beneficial short-term caching can be
with the issue that raises of how best to release the cache, with
parallels to existing caches. 

Hmm, Documentation/vm/highmem.txt:

==
TEMPORARY VIRTUAL MAPPINGS
==

The kernel contains several ways of creating temporary mappings:

 (*) vmap().  This can be used to make a long duration mapping of multiple
 physical pages into a contiguous virtual space.  It needs global
 synchronization to unmap.


"long duration" but temporary, ok, maybe there's a little more wiggle
room already here for keeping vmappings around. I was under the
impression that vmaps were to only ever be shortlived (due to the
pressure on vmap space).
-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] [RFCv2 02/14] drm/i915/gvt: Introduce the basic architecture of GVT-g

[Joonas Lahtinen]

A one more note below.

On to, 2016-02-18 at 19:42 +0800, Zhi Wang wrote:
> This patch introduces the very basic framework of GVT-g device model,
> includes basic prototypes, definitions, initialization.
> 
> v2:
> - Introduce i915_gvt.c.
> It's necessary to introduce the stubs between i915 driver and GVT-g host,
> as GVT-g components is configurable in kernel config. When disabled, the
> stubs here do nothing.
> 
> Take Joonas's comments:
> - Replace boolean return value with int.
> - Replace customized info/warn/debug macros with DRM macros.
> - Document all non-static functions like i915.
> - Remove empty and unused functions.
> - Replace magic number with marcos.
> - Set GVT-g in kernel config to "n" by default.
> 
> Signed-off-by: Zhi Wang 
> ---
>  drivers/gpu/drm/i915/Kconfig |  15 ++
>  drivers/gpu/drm/i915/Makefile|   2 +
>  drivers/gpu/drm/i915/gvt/Makefile|   5 +
>  drivers/gpu/drm/i915/gvt/debug.h |  57 +
>  drivers/gpu/drm/i915/gvt/gvt.c   | 393 
> +++
>  drivers/gpu/drm/i915/gvt/gvt.h   | 100 +
>  drivers/gpu/drm/i915/gvt/hypercall.h |  30 +++
>  drivers/gpu/drm/i915/gvt/mpt.h   |  34 +++
>  drivers/gpu/drm/i915/gvt/params.c|  32 +++
>  drivers/gpu/drm/i915/gvt/params.h|  34 +++
>  drivers/gpu/drm/i915/gvt/reg.h   |  34 +++
>  drivers/gpu/drm/i915/i915_dma.c  |  14 ++
>  drivers/gpu/drm/i915/i915_drv.h  |  12 ++
>  drivers/gpu/drm/i915/i915_gvt.c  |  93 +
>  drivers/gpu/drm/i915/i915_gvt.h  |  49 +
>  15 files changed, 904 insertions(+)
>  create mode 100644 drivers/gpu/drm/i915/gvt/Makefile
>  create mode 100644 drivers/gpu/drm/i915/gvt/debug.h
>  create mode 100644 drivers/gpu/drm/i915/gvt/gvt.c
>  create mode 100644 drivers/gpu/drm/i915/gvt/gvt.h
>  create mode 100644 drivers/gpu/drm/i915/gvt/hypercall.h
>  create mode 100644 drivers/gpu/drm/i915/gvt/mpt.h
>  create mode 100644 drivers/gpu/drm/i915/gvt/params.c
>  create mode 100644 drivers/gpu/drm/i915/gvt/params.h
>  create mode 100644 drivers/gpu/drm/i915/gvt/reg.h
>  create mode 100644 drivers/gpu/drm/i915/i915_gvt.c
>  create mode 100644 drivers/gpu/drm/i915/i915_gvt.h
> 
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index 4c59793..082e77d 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -45,3 +45,18 @@ config DRM_I915_PRELIMINARY_HW_SUPPORT
>     option changes the default for that module option.
>  
>     If in doubt, say "N".
> +
> +config DRM_I915_GVT
> +tristate "GVT-g host driver"
> +depends on DRM_I915
> +default n
> +help
> +  Enabling GVT-g mediated graphics passthrough technique for Intel 
> i915
> +  based integrated graphics card. With GVT-g, it's possible to have 
> one
> +  integrated i915 device shared by multiple VMs. Performance critical
> +  opterations such as apperture accesses and ring buffer operations
> +  are pass-throughed to VM, with a minimal set of conflicting 
> resources
> +  (e.g. display settings) mediated by vGT driver. The benefit of vGT
> +  is on both the performance, given that each VM could directly 
> operate
> +  its aperture space and submit commands like running on native, and
> +  the feature completeness, given that a true GEN hardware is 
> exposed.
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 0851de07..c65026c 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -91,6 +91,8 @@ i915-y += dvo_ch7017.o \
>     intel_sdvo.o \
>     intel_tv.o
>  
> +obj-$(CONFIG_DRM_I915_GVT)  += i915_gvt.o gvt/
> +
>  # virtual gpu code
>  i915-y += i915_vgpu.o
>  
> diff --git a/drivers/gpu/drm/i915/gvt/Makefile 
> b/drivers/gpu/drm/i915/gvt/Makefile
> new file mode 100644
> index 000..959305f
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/gvt/Makefile
> @@ -0,0 +1,5 @@
> +GVT_SOURCE := gvt.o params.o
> +
> +ccflags-y  += -I$(src) -I$(src)/.. -Wall -Werror 
> -Wno-unused-function
> +i915_gvt-y := $(GVT_SOURCE)

(This name conflicts with upper level i915_gvt, which I suggested
renaming to intel_gvt.c. A one more reason more so this can be kept as
is).

As the module will be called i915_gvt, I bet the debug prefix should be
changed to reflect that.

So it should look like;

${WHATEVER_DRM_PRINTS} i915-gvt: core: Core debug
${WHATEVER_DRM_PRINTS} i915-gvt: mm: Memory debug

Regards, Joonas

> +obj-$(CONFIG_DRM_I915_GVT) += i915_gvt.o
> diff --git a/drivers/gpu/drm/i915/gvt/debug.h 
> b/drivers/gpu/drm/i915/gvt/debug.h
> new file mode 100644
> index 000..0747f28
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/gvt/debug.h
> @@ -0,0 +1,57 @@
> +/*
> + * Copyright(c) 2011-2016 Intel Corporation. All rights reserved.
> + *
> + * Permission is hereby granted, free of 

[Intel-gfx] [PATCH] drm/i915: factor out i915_pvinfo.h

[Zhi Wang]

As the PVINFO page definition is used by both GVT-g guest (vGPU) and GVT-g
host (GVT-g kernel device model), factor it out for better code structure.

v2:
- Use offsetof() to calculate the offset of PVINFO member(Joonas)

Signed-off-by: Zhi Wang 
---
 drivers/gpu/drm/i915/i915_pvinfo.h | 113 +
 drivers/gpu/drm/i915/i915_vgpu.h   |  86 +---
 2 files changed, 114 insertions(+), 85 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_pvinfo.h

diff --git a/drivers/gpu/drm/i915/i915_pvinfo.h 
b/drivers/gpu/drm/i915/i915_pvinfo.h
new file mode 100644
index 000..7b3cec4
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_pvinfo.h
@@ -0,0 +1,113 @@
+/*
+ * Copyright(c) 2011-2016 Intel Corporation. All rights reserved.
+ *
+ * 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.
+ */
+
+#ifndef _I915_PVINFO_H_
+#define _I915_PVINFO_H_
+
+/* The MMIO offset of the shared info between guest and host emulator */
+#define VGT_PVINFO_PAGE0x78000
+#define VGT_PVINFO_SIZE0x1000
+
+/*
+ * The following structure pages are defined in GEN MMIO space
+ * for virtualization. (One page for now)
+ */
+#define VGT_MAGIC 0x4776544776544776ULL/* 'vGTvGTvG' */
+#define VGT_VERSION_MAJOR 1
+#define VGT_VERSION_MINOR 0
+
+#define INTEL_VGT_IF_VERSION_ENCODE(major, minor) ((major) << 16 | (minor))
+#define INTEL_VGT_IF_VERSION \
+   INTEL_VGT_IF_VERSION_ENCODE(VGT_VERSION_MAJOR, VGT_VERSION_MINOR)
+
+/*
+ * notifications from guest to vgpu device model
+ */
+enum vgt_g2v_type {
+   VGT_G2V_PPGTT_L3_PAGE_TABLE_CREATE = 2,
+   VGT_G2V_PPGTT_L3_PAGE_TABLE_DESTROY,
+   VGT_G2V_PPGTT_L4_PAGE_TABLE_CREATE,
+   VGT_G2V_PPGTT_L4_PAGE_TABLE_DESTROY,
+   VGT_G2V_EXECLIST_CONTEXT_CREATE,
+   VGT_G2V_EXECLIST_CONTEXT_DESTROY,
+   VGT_G2V_MAX,
+};
+
+struct vgt_if {
+   uint64_t magic; /* VGT_MAGIC */
+   uint16_t version_major;
+   uint16_t version_minor;
+   uint32_t vgt_id;/* ID of vGT instance */
+   uint32_t rsv1[12];  /* pad to offset 0x40 */
+   /*
+*  Data structure to describe the balooning info of resources.
+*  Each VM can only have one portion of continuous area for now.
+*  (May support scattered resource in future)
+*  (starting from offset 0x40)
+*/
+   struct {
+   /* Aperture register balooning */
+   struct {
+   uint32_t base;
+   uint32_t size;
+   } mappable_gmadr;   /* aperture */
+   /* GMADR register balooning */
+   struct {
+   uint32_t base;
+   uint32_t size;
+   } nonmappable_gmadr;/* non aperture */
+   /* allowed fence registers */
+   uint32_t fence_num;
+   uint32_t rsv2[3];
+   } avail_rs; /* available/assigned resource */
+   uint32_t rsv3[0x200 - 24];  /* pad to half page */
+   /*
+* The bottom half page is for response from Gfx driver to hypervisor.
+*/
+   uint32_t rsv4;
+   uint32_t display_ready; /* ready for display owner switch */
+
+   uint32_t rsv5[4];
+
+   uint32_t g2v_notify;
+   uint32_t rsv6[7];
+
+   struct {
+   uint32_t lo;
+   uint32_t hi;
+   } pdp[4];
+
+   uint32_t execlist_context_descriptor_lo;
+   uint32_t execlist_context_descriptor_hi;
+
+   uint32_t  rsv7[0x200 - 24];/* pad to one page */
+} __packed;
+
+#define vgtif_reg(x) \
+   _MMIO((VGT_PVINFO_PAGE + offsetof(struct vgt_if, x)))
+
+/* vGPU display status to be used by the host side */
+#define VGT_DRV_DISPLAY_NOT_READY 0
+#define VGT_DRV_DISPLAY_READY 1  /* ready for display switch */
+
+#endif /* _I915_PVINFO_H_ */
diff --git 

Re: [Intel-gfx] [RFCv2 02/14] drm/i915/gvt: Introduce the basic architecture of GVT-g

[Joonas Lahtinen]

Hi,

Code is looking a lot better.

A general question still; why you seem to be preferring multi-stage
alloc and destroy?

Are there going to be scenarios when things will be allocated but not
initialized? I don't see a such use scenario.

I wouldn't split the init functions down as much as you currently do
because that'll require a lot of boilerplate code to propagate the
errors up, which is currently not done. The boilerplate for propagation
becomes necessary when the teardown function is complex, but currently
the teardown itself is less lines of code than the function
boilerplate.

So just squash those into gvt_device_create() and gvt_device_destroy()
where _create() will propagate any lower level errors up and tear down
a partially initialized struct. _destroy() can then expect to just tear
the whole struct down with no ifs.

Regards, Joonas

On to, 2016-02-18 at 19:42 +0800, Zhi Wang wrote:
> This patch introduces the very basic framework of GVT-g device model,
> includes basic prototypes, definitions, initialization.
> 
> v2:
> - Introduce i915_gvt.c.
> It's necessary to introduce the stubs between i915 driver and GVT-g host,
> as GVT-g components is configurable in kernel config. When disabled, the
> stubs here do nothing.
> 
> Take Joonas's comments:
> - Replace boolean return value with int.
> - Replace customized info/warn/debug macros with DRM macros.
> - Document all non-static functions like i915.
> - Remove empty and unused functions.
> - Replace magic number with marcos.
> - Set GVT-g in kernel config to "n" by default.
> 
> Signed-off-by: Zhi Wang 
> ---
>  drivers/gpu/drm/i915/Kconfig |  15 ++
>  drivers/gpu/drm/i915/Makefile|   2 +
>  drivers/gpu/drm/i915/gvt/Makefile|   5 +
>  drivers/gpu/drm/i915/gvt/debug.h |  57 +
>  drivers/gpu/drm/i915/gvt/gvt.c   | 393 
> +++
>  drivers/gpu/drm/i915/gvt/gvt.h   | 100 +
>  drivers/gpu/drm/i915/gvt/hypercall.h |  30 +++
>  drivers/gpu/drm/i915/gvt/mpt.h   |  34 +++
>  drivers/gpu/drm/i915/gvt/params.c|  32 +++
>  drivers/gpu/drm/i915/gvt/params.h|  34 +++
>  drivers/gpu/drm/i915/gvt/reg.h   |  34 +++
>  drivers/gpu/drm/i915/i915_dma.c  |  14 ++
>  drivers/gpu/drm/i915/i915_drv.h  |  12 ++
>  drivers/gpu/drm/i915/i915_gvt.c  |  93 +
>  drivers/gpu/drm/i915/i915_gvt.h  |  49 +
>  15 files changed, 904 insertions(+)
>  create mode 100644 drivers/gpu/drm/i915/gvt/Makefile
>  create mode 100644 drivers/gpu/drm/i915/gvt/debug.h
>  create mode 100644 drivers/gpu/drm/i915/gvt/gvt.c
>  create mode 100644 drivers/gpu/drm/i915/gvt/gvt.h
>  create mode 100644 drivers/gpu/drm/i915/gvt/hypercall.h
>  create mode 100644 drivers/gpu/drm/i915/gvt/mpt.h
>  create mode 100644 drivers/gpu/drm/i915/gvt/params.c
>  create mode 100644 drivers/gpu/drm/i915/gvt/params.h
>  create mode 100644 drivers/gpu/drm/i915/gvt/reg.h
>  create mode 100644 drivers/gpu/drm/i915/i915_gvt.c
>  create mode 100644 drivers/gpu/drm/i915/i915_gvt.h
> 
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index 4c59793..082e77d 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -45,3 +45,18 @@ config DRM_I915_PRELIMINARY_HW_SUPPORT
>     option changes the default for that module option.
>  
>     If in doubt, say "N".
> +
> +config DRM_I915_GVT
> +tristate "GVT-g host driver"
> +depends on DRM_I915
> +default n
> +help
> +  Enabling GVT-g mediated graphics passthrough technique for Intel 
> i915
> +  based integrated graphics card. With GVT-g, it's possible to have 
> one
> +  integrated i915 device shared by multiple VMs. Performance critical
> +  opterations such as apperture accesses and ring buffer operations
> +  are pass-throughed to VM, with a minimal set of conflicting 
> resources
> +  (e.g. display settings) mediated by vGT driver. The benefit of vGT
> +  is on both the performance, given that each VM could directly 
> operate
> +  its aperture space and submit commands like running on native, and
> +  the feature completeness, given that a true GEN hardware is 
> exposed.
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 0851de07..c65026c 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -91,6 +91,8 @@ i915-y += dvo_ch7017.o \
>     intel_sdvo.o \
>     intel_tv.o
>  
> +obj-$(CONFIG_DRM_I915_GVT)  += i915_gvt.o gvt/
> +
>  # virtual gpu code
>  i915-y += i915_vgpu.o
>  
> diff --git a/drivers/gpu/drm/i915/gvt/Makefile 
> b/drivers/gpu/drm/i915/gvt/Makefile
> new file mode 100644
> index 000..959305f
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/gvt/Makefile
> @@ -0,0 +1,5 @@
> +GVT_SOURCE := gvt.o params.o
> +
> +ccflags-y  += -I$(src) -I$(src)/.. -Wall -Werror 
> 

Re: [Intel-gfx] [PATCH v4 2/3] drm/i915: refactor duplicate object vmap functions (reworked)

[Tvrtko Ursulin]

On 23/02/16 11:52, Chris Wilson wrote:

On Tue, Feb 23, 2016 at 11:38:02AM +, Chris Wilson wrote:

Indeed, we would need a new notifier, pretty much for the sole use of
32b. Grr, that will be a nuisance.


Core changes:

diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h
index d1f1d338af20..542a91c2785f 100644
--- a/include/linux/vmalloc.h
+++ b/include/linux/vmalloc.h
@@ -187,4 +187,8 @@ pcpu_free_vm_areas(struct vm_struct **vms, int nr_vms)
  #define VMALLOC_TOTAL 0UL
  #endif

+struct notitifer_block;
+int register_vmap_notifier(struct notifier_block *nb);
+int unregister_vmap_notifier(struct notifier_block *nb);
+
  #endif /* _LINUX_VMALLOC_H */
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index fb42a5bffe47..0735d82444f7 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -21,6 +21,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -344,6 +345,8 @@ static void __insert_vmap_area(struct vmap_area *va)

  static void purge_vmap_area_lazy(void);

+static BLOCKING_NOTIFIER_HEAD(vmap_notify_list);
+
  /*
   * Allocate a region of KVA of the specified size and alignment, within the
   * vstart and vend.
@@ -356,6 +359,7 @@ static struct vmap_area *alloc_vmap_area(unsigned long size,
 struct vmap_area *va;
 struct rb_node *n;
 unsigned long addr;
+   unsigned long freed;
 int purged = 0;
 struct vmap_area *first;

@@ -468,6 +472,12 @@ overflow:
 purged = 1;
 goto retry;
 }
+   freed = 0;
+   blocking_notifier_call_chain(_notify_list, 0, );
+   if (freed > 0) {
+   purged = 0;
+   goto retry;
+   }
 if (printk_ratelimit())
 pr_warn("vmap allocation for size %lu failed: "
 "use vmalloc= to increase size.\n", size);
@@ -475,6 +485,18 @@ overflow:
 return ERR_PTR(-EBUSY);
  }

+int register_vmap_notifier(struct notifier_block *nb)
+{
+   return blocking_notifier_chain_register(_notify_list, nb);
+}
+EXPORT_SYMBOL_GPL(register_vmap_notifier);
+
+int unregister_vmap_notifier(struct notifier_block *nb)
+{
+   return blocking_notifier_chain_unregister(_notify_list, nb);
+}
+EXPORT_SYMBOL_GPL(unregister_vmap_notifier);
+
  static void __free_vmap_area(struct vmap_area *va)
  {
 BUG_ON(RB_EMPTY_NODE(>rb_node));


That doesn't look too horrendous. Names?


Downside is new deadlock opportunity so GEM callers to vmap would have 
to release the struct mutex.



register_oovmap_notifier
register_vmap_nospace_notifier?
register_vmap_purge_notifier?


register_vmap_shrinker ?


And the 64k question, how to sell it?


Not sure, maybe with numbers showing that caching the vmapping helps us 
significantly?


Regards,

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

[Intel-gfx] ✗ Fi.CI.BAT: warning for kernfs: Move faulting copy_user operations outside of the mutex

[Patchwork]

== Series Details ==

Series: kernfs: Move faulting copy_user operations outside of the mutex
URL   : https://patchwork.freedesktop.org/series/3722/
State : warning

== Summary ==

Series 3722v1 kernfs: Move faulting copy_user operations outside of the mutex
http://patchwork.freedesktop.org/api/1.0/series/3722/revisions/1/mbox/

Test gem_cs_prefetch:
Subgroup basic-default:
incomplete -> PASS   (ilk-hp8440p)
Test gem_mmap:
Subgroup basic-small-bo:
pass   -> DMESG-WARN (byt-nuc)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass   -> DMESG-WARN (ilk-hp8440p) UNSTABLE
Test kms_force_connector_basic:
Subgroup force-edid:
skip   -> PASS   (snb-x220t)
Subgroup force-load-detect:
dmesg-fail -> FAIL   (snb-x220t)
dmesg-fail -> FAIL   (snb-dellxps)
dmesg-fail -> FAIL   (hsw-gt2)
fail   -> DMESG-FAIL (ilk-hp8440p)
Test pm_rpm:
Subgroup basic-pci-d3-state:
pass   -> DMESG-WARN (byt-nuc)
Subgroup basic-rte:
dmesg-warn -> PASS   (byt-nuc) UNSTABLE

bdw-nuci7total:165  pass:154  dwarn:0   dfail:0   fail:0   skip:11 
bdw-ultratotal:168  pass:154  dwarn:0   dfail:0   fail:0   skip:14 
bsw-nuc-2total:168  pass:137  dwarn:0   dfail:0   fail:1   skip:30 
byt-nuc  total:168  pass:141  dwarn:2   dfail:0   fail:0   skip:25 
hsw-gt2  total:168  pass:157  dwarn:0   dfail:0   fail:1   skip:10 
ilk-hp8440p  total:168  pass:117  dwarn:1   dfail:1   fail:0   skip:49 
ivb-t430stotal:168  pass:153  dwarn:0   dfail:0   fail:1   skip:14 
skl-i5k-2total:168  pass:151  dwarn:1   dfail:0   fail:0   skip:16 
snb-dellxps  total:168  pass:145  dwarn:0   dfail:0   fail:1   skip:22 
snb-x220ttotal:168  pass:145  dwarn:0   dfail:0   fail:2   skip:21 

Results at /archive/results/CI_IGT_test/Patchwork_1462/

08fc1b101049694778bff7559e1d05250d2e7072 drm-intel-nightly: 
2016y-02m-22d-17h-30m-27s UTC integration manifest
dc8e366ef07e96a013c3910d0ce38a9aac2f292d kernfs: Move faulting copy_user 
operations outside of the mutex

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

Re: [Intel-gfx] [PATCH v4 2/3] drm/i915: refactor duplicate object vmap functions (reworked)

[Chris Wilson]

On Tue, Feb 23, 2016 at 11:38:02AM +, Chris Wilson wrote:
> Indeed, we would need a new notifier, pretty much for the sole use of
> 32b. Grr, that will be a nuisance.

Core changes:

diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h
index d1f1d338af20..542a91c2785f 100644
--- a/include/linux/vmalloc.h
+++ b/include/linux/vmalloc.h
@@ -187,4 +187,8 @@ pcpu_free_vm_areas(struct vm_struct **vms, int nr_vms)
 #define VMALLOC_TOTAL 0UL
 #endif
 
+struct notitifer_block;
+int register_vmap_notifier(struct notifier_block *nb);
+int unregister_vmap_notifier(struct notifier_block *nb);
+
 #endif /* _LINUX_VMALLOC_H */
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index fb42a5bffe47..0735d82444f7 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -344,6 +345,8 @@ static void __insert_vmap_area(struct vmap_area *va)
 
 static void purge_vmap_area_lazy(void);
 
+static BLOCKING_NOTIFIER_HEAD(vmap_notify_list);
+
 /*
  * Allocate a region of KVA of the specified size and alignment, within the
  * vstart and vend.
@@ -356,6 +359,7 @@ static struct vmap_area *alloc_vmap_area(unsigned long size,
struct vmap_area *va;
struct rb_node *n;
unsigned long addr;
+   unsigned long freed;
int purged = 0;
struct vmap_area *first;
 
@@ -468,6 +472,12 @@ overflow:
purged = 1;
goto retry;
}
+   freed = 0;
+   blocking_notifier_call_chain(_notify_list, 0, );
+   if (freed > 0) {
+   purged = 0;
+   goto retry;
+   }
if (printk_ratelimit())
pr_warn("vmap allocation for size %lu failed: "
"use vmalloc= to increase size.\n", size);
@@ -475,6 +485,18 @@ overflow:
return ERR_PTR(-EBUSY);
 }
 
+int register_vmap_notifier(struct notifier_block *nb)
+{
+   return blocking_notifier_chain_register(_notify_list, nb);
+}
+EXPORT_SYMBOL_GPL(register_vmap_notifier);
+
+int unregister_vmap_notifier(struct notifier_block *nb)
+{
+   return blocking_notifier_chain_unregister(_notify_list, nb);
+}
+EXPORT_SYMBOL_GPL(unregister_vmap_notifier);
+
 static void __free_vmap_area(struct vmap_area *va)
 {
BUG_ON(RB_EMPTY_NODE(>rb_node));


That doesn't look too horrendous. Names?

register_oovmap_notifier
register_vmap_nospace_notifier?
register_vmap_purge_notifier?

And the 64k question, how to sell it?
-Chris

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

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Avoid selecting unavailable BSD2 ring (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Avoid selecting unavailable BSD2 ring (rev2)
URL   : https://patchwork.freedesktop.org/series/3678/
State : warning

== Summary ==

Series 3678v2 drm/i915: Avoid selecting unavailable BSD2 ring
http://patchwork.freedesktop.org/api/1.0/series/3678/revisions/2/mbox/

Test gem_cs_prefetch:
Subgroup basic-default:
incomplete -> PASS   (ilk-hp8440p)
Test kms_force_connector_basic:
Subgroup force-edid:
skip   -> PASS   (snb-x220t)
Subgroup force-load-detect:
dmesg-fail -> FAIL   (snb-x220t)
dmesg-fail -> FAIL   (snb-dellxps)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (skl-i5k-2) UNSTABLE
Subgroup suspend-read-crc-pipe-c:
pass   -> DMESG-WARN (skl-i5k-2) UNSTABLE
Test pm_rpm:
Subgroup basic-pci-d3-state:
pass   -> DMESG-WARN (bsw-nuc-2)

bdw-nuci7total:165  pass:154  dwarn:0   dfail:0   fail:0   skip:11 
bdw-ultratotal:168  pass:154  dwarn:0   dfail:0   fail:0   skip:14 
bsw-nuc-2total:168  pass:136  dwarn:1   dfail:0   fail:1   skip:30 
byt-nuc  total:168  pass:142  dwarn:1   dfail:0   fail:0   skip:25 
hsw-gt2  total:168  pass:157  dwarn:0   dfail:1   fail:0   skip:10 
ilk-hp8440p  total:168  pass:118  dwarn:0   dfail:0   fail:1   skip:49 
ivb-t430stotal:168  pass:153  dwarn:0   dfail:0   fail:1   skip:14 
skl-i5k-2total:168  pass:151  dwarn:1   dfail:0   fail:0   skip:16 
snb-dellxps  total:168  pass:145  dwarn:0   dfail:0   fail:1   skip:22 
snb-x220ttotal:168  pass:145  dwarn:0   dfail:0   fail:2   skip:21 

Results at /archive/results/CI_IGT_test/Patchwork_1461/

08fc1b101049694778bff7559e1d05250d2e7072 drm-intel-nightly: 
2016y-02m-22d-17h-30m-27s UTC integration manifest
6afb1e4a01be18acf8e5c117977004750bacf4b8 drm/i915: Avoid selecting unavailable 
BSD2 ring

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

[Intel-gfx] [PATCH] kernfs: Move faulting copy_user operations outside of the mutex

[Chris Wilson]

A fault in a user provided buffer may lead anywhere, and lockdep warns
that we have a potential deadlock between the mm->mmap_sem and the
kernfs file mutex:

[   82.811702] ==
[   82.811705] [ INFO: possible circular locking dependency detected ]
[   82.811709] 4.5.0-rc4-gfxbench+ #1 Not tainted
[   82.811711] ---
[   82.811714] kms_setmode/5859 is trying to acquire lock:
[   82.811717]  (>struct_mutex){+.+.+.}, at: [] 
drm_gem_mmap+0x1a1/0x270
[   82.811731]
but task is already holding lock:
[   82.811734]  (>mmap_sem){++}, at: [] 
vm_mmap_pgoff+0x44/0xa0
[   82.811745]
which lock already depends on the new lock.

[   82.811749]
the existing dependency chain (in reverse order) is:
[   82.811752]
-> #3 (>mmap_sem){++}:
[   82.811761][] lock_acquire+0xc3/0x1d0
[   82.811766][] __might_fault+0x75/0xa0
[   82.811771][] kernfs_fop_write+0x8a/0x180
[   82.811787][] __vfs_write+0x23/0xe0
[   82.811792][] vfs_write+0xa4/0x190
[   82.811797][] SyS_write+0x44/0xb0
[   82.811801][] entry_SYSCALL_64_fastpath+0x16/0x73
[   82.811807]
-> #2 (s_active#6){.+}:
[   82.811814][] lock_acquire+0xc3/0x1d0
[   82.811819][] __kernfs_remove+0x210/0x2f0
[   82.811823][] kernfs_remove_by_name_ns+0x40/0xa0
[   82.811828][] sysfs_remove_file_ns+0x10/0x20
[   82.811832][] device_del+0x124/0x250
[   82.811837][] device_unregister+0x19/0x60
[   82.811841][] cpu_cache_sysfs_exit+0x51/0xb0
[   82.811846][] cacheinfo_cpu_callback+0x38/0x70
[   82.811851][] notifier_call_chain+0x39/0xa0
[   82.811856][] __raw_notifier_call_chain+0x9/0x10
[   82.811860][] cpu_notify+0x1e/0x40
[   82.811865][] cpu_notify_nofail+0x9/0x20
[   82.811869][] _cpu_down+0x233/0x340
[   82.811874][] disable_nonboot_cpus+0xc9/0x350
[   82.811878][] suspend_devices_and_enter+0x5a1/0xb50
[   82.811883][] pm_suspend+0x543/0x8d0
[   82.811888][] state_store+0x77/0xe0
[   82.811892][] kobj_attr_store+0xf/0x20
[   82.811897][] sysfs_kf_write+0x40/0x50
[   82.811902][] kernfs_fop_write+0x13c/0x180
[   82.811906][] __vfs_write+0x23/0xe0
[   82.811910][] vfs_write+0xa4/0x190
[   82.811914][] SyS_write+0x44/0xb0
[   82.811918][] entry_SYSCALL_64_fastpath+0x16/0x73
[   82.811923]
-> #1 (cpu_hotplug.lock){+.+.+.}:
[   82.811929][] lock_acquire+0xc3/0x1d0
[   82.811933][] mutex_lock_nested+0x62/0x3b0
[   82.811940][] get_online_cpus+0x61/0x80
[   82.811944][] stop_machine+0x1b/0xe0
[   82.811949][] 
gen8_ggtt_insert_entries__BKL+0x2d/0x30 [i915]
[   82.812009][] ggtt_bind_vma+0x46/0x70 [i915]
[   82.812045][] i915_vma_bind+0x140/0x290 [i915]
[   82.812081][] i915_gem_object_do_pin+0x899/0xb00 
[i915]
[   82.812117][] i915_gem_object_pin+0x35/0x40 [i915]
[   82.812154][] intel_init_pipe_control+0xbe/0x210 
[i915]
[   82.812192][] intel_logical_rings_init+0xe2/0xde0 
[i915]
[   82.812232][] i915_gem_init+0xf3/0x130 [i915]
[   82.812278][] i915_driver_load+0xf2d/0x1770 [i915]
[   82.812318][] drm_dev_register+0xa4/0xb0
[   82.812323][] drm_get_pci_dev+0xce/0x1e0
[   82.812328][] i915_pci_probe+0x2f/0x50 [i915]
[   82.812360][] pci_device_probe+0x87/0xf0
[   82.812366][] driver_probe_device+0x229/0x450
[   82.812371][] __driver_attach+0x83/0x90
[   82.812375][] bus_for_each_dev+0x61/0xa0
[   82.812380][] driver_attach+0x19/0x20
[   82.812384][] bus_add_driver+0x1ef/0x290
[   82.812388][] driver_register+0x5b/0xe0
[   82.812393][] __pci_register_driver+0x5b/0x60
[   82.812398][] drm_pci_init+0xd6/0x100
[   82.812402][] 0xa027c094
[   82.812406][] do_one_initcall+0xae/0x1d0
[   82.812412][] do_init_module+0x5b/0x1cb
[   82.812417][] load_module+0x1c20/0x2480
[   82.812422][] SyS_finit_module+0x7e/0xa0
[   82.812428][] entry_SYSCALL_64_fastpath+0x16/0x73
[   82.812433]
-> #0 (>struct_mutex){+.+.+.}:
[   82.812439][] __lock_acquire+0x1fc9/0x20f0
[   82.812443][] lock_acquire+0xc3/0x1d0
[   82.812456][] drm_gem_mmap+0x1c7/0x270
[   82.812460][] mmap_region+0x334/0x580
[   82.812466][] do_mmap+0x364/0x410
[   82.812470][] vm_mmap_pgoff+0x6d/0xa0
[   82.812474][] SyS_mmap_pgoff+0x184/0x220
[   82.812479][] SyS_mmap+0x1d/0x20
[   82.812484][] entry_SYSCALL_64_fastpath+0x16/0x73
[   82.812489]
other info that might help us debug this:

[   82.812493] Chain exists of:
  >struct_mutex --> s_active#6 --> >mmap_sem

[   82.812502]  Possible unsafe locking scenario:

[   82.812506]CPU0CPU1

Re: [Intel-gfx] [PATCH v4 2/3] drm/i915: refactor duplicate object vmap functions (reworked)

[Chris Wilson]

On Tue, Feb 23, 2016 at 10:31:08AM +, Tvrtko Ursulin wrote:
> 
> On 23/02/16 10:06, Chris Wilson wrote:
> >On Mon, Feb 22, 2016 at 04:06:39PM +, Tvrtko Ursulin wrote:
> >>
> >>[Cc Chris as the author of the idea.]
> >>
> >>Hi,
> >>
> >>On 22/02/16 15:18, Dave Gordon wrote:
> >>>This is essentially Chris Wilson's patch of a similar name, reworked on
> >>>top of Alex Dai's recent patch:
> >>>   drm/i915: Add i915_gem_object_vmap to map GEM object to virtual space
> >>>Chris' original commentary said:
> >>>
> >>>   We now have two implementations for vmapping a whole object, one for
> >>>   dma-buf and one for the ringbuffer. If we couple the vmapping into
> >>>   the obj->pages lifetime, then we can reuse an obj->vmapping for both
> >>>   and at the same time couple it into the shrinker.
> >>
> >>As a general concept my worry is that by implementing this approach
> >>we tie two unrelated concepts together.
> >>
> >>Shrinker is about backing storage (used/free pages in a machine),
> >>while vmap is about kernel address space. And then on 32-bit with
> >>its limited vmap space (128MiB, right?), it can become exhausted
> >>much sooner that the shrinker would be triggered. And we would rely
> >>on the shrinker running to free up address space as well now, right?
> >
> >Yes, we use the shrinker to free address space.
> >
> >>So unless I am missing something that doesn't fit well.
> >
> >The opposite. Even more reason for the shrinker to be able to recover
> >vmap space on 32bit systems (for external users, not just ourselves).
> 
> How? I don't see that failed vmapping will trigger shrinking. What
> will prevent i915 from accumulating objects with vmaps sticking
> around for too long potentially?

I read what you wrote as implying the shrinker would be run (which is
what I hoped). I made the mistake of just thinking of the allocations
around that path, rather than alloc_vmap_area().

Indeed, we would need a new notifier, pretty much for the sole use of
32b. Grr, that will be a nuisance.

> >>But as a related question, I wonder why doesn't the LRC require the
> >>same !HAS_LLC approach when mapping as ring buffer does here?
> >
> >We don't try to use stolen for LRC. The main difficulty lies in
> >deciding how to map the state object, stolen forces us to use an
> >ioremapping through the GTT and so only suitable for write-only
> >mappings. However, we could be using the per-context HWS, for which we
> >want a CPU accessible, direct pointer.
> 
> I wasn't asking about stolen but the !HAS_LLC path. Even non-stolen
> ring buffers will be mapped vie the aperture on !HAS_LLC platforms.
> That implies it is about cache coherency and we don't have the same
> treatment for the LRC page.

Oh, completely missed the point. Yes, I also wonder how the kmap() on
the context object works for Braswell without an explicit clflush of at
least the TAIL update between requests.

> Until your vma->iomap prototype which added the same uncached access
> to the LRC as well.
> 
> So my question was, do we need this for cache considerations today,
> irrespective of caching the pointer in the VMA.

Yes, I think so, but it's hard to say as Braswell breaks in so many
different ways when the littlest of stress is applied.
-Chris

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

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/gen9: Set value of Indirect Context Offset based on gen version (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915/gen9: Set value of Indirect Context Offset based on gen 
version (rev4)
URL   : https://patchwork.freedesktop.org/series/3629/
State : warning

== Summary ==

Series 3629v4 drm/i915/gen9: Set value of Indirect Context Offset based on gen 
version
http://patchwork.freedesktop.org/api/1.0/series/3629/revisions/4/mbox/

Test gem_cs_prefetch:
Subgroup basic-default:
incomplete -> PASS   (ilk-hp8440p)
Test kms_force_connector_basic:
Subgroup force-edid:
skip   -> PASS   (snb-x220t)
Subgroup force-load-detect:
dmesg-fail -> FAIL   (snb-x220t)
dmesg-fail -> FAIL   (snb-dellxps)
fail   -> DMESG-FAIL (ilk-hp8440p)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (skl-i5k-2) UNSTABLE
pass   -> DMESG-WARN (ilk-hp8440p)
Subgroup suspend-read-crc-pipe-c:
pass   -> DMESG-WARN (skl-i5k-2) UNSTABLE
pass   -> DMESG-WARN (bsw-nuc-2)
Test pm_rpm:
Subgroup basic-pci-d3-state:
pass   -> DMESG-WARN (bsw-nuc-2)

bdw-nuci7total:165  pass:154  dwarn:0   dfail:0   fail:0   skip:11 
bdw-ultratotal:168  pass:154  dwarn:0   dfail:0   fail:0   skip:14 
bsw-nuc-2total:168  pass:135  dwarn:2   dfail:0   fail:1   skip:30 
byt-nuc  total:168  pass:142  dwarn:1   dfail:0   fail:0   skip:25 
hsw-gt2  total:168  pass:157  dwarn:0   dfail:1   fail:0   skip:10 
ilk-hp8440p  total:168  pass:117  dwarn:1   dfail:1   fail:0   skip:49 
ivb-t430stotal:168  pass:153  dwarn:0   dfail:0   fail:1   skip:14 
skl-i5k-2total:168  pass:151  dwarn:1   dfail:0   fail:0   skip:16 
snb-dellxps  total:168  pass:145  dwarn:0   dfail:0   fail:1   skip:22 
snb-x220ttotal:168  pass:145  dwarn:0   dfail:0   fail:2   skip:21 

Results at /archive/results/CI_IGT_test/Patchwork_1460/

08fc1b101049694778bff7559e1d05250d2e7072 drm-intel-nightly: 
2016y-02m-22d-17h-30m-27s UTC integration manifest
644bbd41dad8857b829a3c627d951873592a7f63 drm/i915/gen9: Set value of Indirect 
Context Offset based on gen version

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

Re: [Intel-gfx] System freeze apparently due to GPU memory exhaustion - why?

[Adam Nielsen]

> Can you attach a full dmesg from boot until the problem appears?

Attached, thanks for your reply.

You can ignore the problem at T=1032000, that was a broken floppy disk
in a USB floppy drive.  The first possibly-GPU-related problem starts
at T=2121945 then the same problem happens immediately following in the
log at T=2128002.

It may be of relevance to note that after a reboot it can take a while
for the problem to surface, but if X crashes due to this issue and I
restart X immediately, then it can be only a matter of minutes to
hours until the problem happens again.

Many thanks,
Adam.


dmesg.txt.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5 09/35] drm/i915: Force MMIO flips when scheduler enabled

[Chris Wilson]

On Mon, Feb 22, 2016 at 12:42:48PM -0800, Jesse Barnes wrote:
> On 02/20/2016 01:22 AM, Chris Wilson wrote:
> > On Fri, Feb 19, 2016 at 11:28:05AM -0800, Jesse Barnes wrote:
> >> On 02/18/2016 06:26 AM, john.c.harri...@intel.com wrote:
> >>> From: John Harrison 
> >>>
> >>> MMIO flips are the preferred mechanism now
> > 
> > Because introducing variable latency in waking up a big core is a good
> > idea?
> 
> Is the latency variability really that bad?  I'm not too concerned about 
> waking up the core either, I think it's going to be hit up quite a bit in 
> these situations anyway, and vblanks should be driving the rendering as well.

The workqueue we use is subject to being preempted by the user, so the
latency can be made arbitrarily large. Also, we don't control what tasks
are ahead of the flip.
 
> >> but more importantly, pipe
> >>> based flips cause issues for the scheduler. Specifically, submitting
> >>> work to the rings around the side of the scheduler could cause that
> >>> work to be lost if the scheduler generates a pre-emption event on that
> >>> ring.
> > 
> > No. That is just incredibily bad design.
> > 
> >> Why can't we use mmio flips unconditionally?  Maarten or Ville?
> > 
> > Why would we want to? CS flips work just fine in execlists and no reason
> > was ever given as to why they were not enabled, just laziness.
> 
> I'm not saying it can't be done, but I thought with atomic we decided to go 
> with mmio because it makes things a lot simpler (iirc Ville's design did that 
> way back?).

My point is that the interface to the scheduler excludes even the
possibility of doing so because it is not cleanly segrated into a tool
for determining the next request to execute but instead subsumes half of
GEM and half of the engine backend becoming another unwanted midlayer
incorporating its own policy. The scheduler doesn't even deal in
requests, which is what prevents us from constructing a request here
with the known dependency and passing it to the scheduler for execution.

As I saw it, CS flips would be one of the best demonstrations for a
scheduler - because to execute the flip within the deadline should
cause a priority boost for all the prerequisites, and then ideally
reduce the number of missed target msc under load. (Though we can
equally promote the last_write_request through another scheduler
interface.)
-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: Use SWF06 to figure out max cdclk for BDW

[Ville Syrjälä]

On Tue, Feb 23, 2016 at 04:22:01PM +0530, Thulasimani, Sivakumar wrote:
> 
> 
> On 2/16/2016 3:35 PM, Ville Syrjälä wrote:
> > On Tue, Feb 16, 2016 at 07:13:05AM +0530, Thulasimani, Sivakumar wrote:
> >>
> >> On 2/12/2016 8:36 PM, ville.syrj...@linux.intel.com wrote:
> >>> From: Ville Syrjälä 
> >>>
> >>> Bspec tells us that we can allow cdclk up to 540Mhz on BDW ULX, or
> >>> up to 675 MHz on ULT, bu only if extra cooling is provided. There
> >>> don't seem to be any strap or VBT bits to tells us this however.
> >>>
> >>> But I did spot something potentially relevant in
> >>> VBIOS_GOP_Driver_SWF_Registers.pdf. Apparently VBIOS/GOP can pass
> >>> the max cdclk frequeny in SWF06 to the driver. Let's assume the firmware
> >>> knows what its doing and trust the max cdclk in SWF06 if it's higher
> >>> than the basic limit specified in Bspec. To avoid regressing anything
> >>> let's ignore SWF06 if it indicates a lower limit than Bspec.
> >>>
> >>> Cc: Clint Taylor 
> >>> Cc: "Thulasimani, Sivakumar" 
> >>> Signed-off-by: Ville Syrjälä 
> >>> ---
> >>>
> >>> I'm not at all sure if this is the right way to go about it. Sivakumar,
> >>> since you seem to have some ideas on this maybe you can have a look.
> >>> I'm not aware of any complaints so far that people can't get the cdclk
> >>> as high is they should on specific machines, so not sure if this is really
> >>> even needed.
> >>>
> >>> The other open question is what we should do if the VBIOS limit is
> >>> lower than what we'd expect based on BSpec. Should we still trust it?
> >>> Sadly we can't verify the SWF06 cdclk value in any way since it
> >>> only has two bits and we have four possible cdclk values.
> >> The value stored in SWF06 is the CD Clock VBIOS/GOP sees during boot. so
> >> it just backs up the CD Clock before it optimizes for the available LFP.
> >> if we
> >> are trusting for higher value we should trust it for lower value too.
> >> The OEM might have did this to either reduce max resolution for cheaper
> >> products or might have removed some cooling mechanisms for thinner
> >> designs since we cannot say which of the reasons we should trust the
> >> lower value too.
> >>
> >> now comes to tough part :(, this SWF06 is saved by VBIOS/GOP driver
> >> from intel alone(it is not programmed from VBT),
> >> since GOP driver can be implemented by anyone and
> >> if anyone implements their own GOP driver we cannot be sure if the
> >> value is valid or not. please check if we can check for "Intel GOP driver".
> >> And if "Intel GOP driver" was used during boot, we can trust the value
> >> 100%.  i am not sure how this can be done, so i would recommend
> >> trusting the values with clear debug messages as done below already.
> > We definitely need a way to validate the register value before we trust
> > it for lower values. I suppose we might be able to look at bits 31:16
> > since those should store the current cdclk "decimal" value. If that part
> > looks reasonable, we might be able to trust the "max cdclk" bits as well.
> it seems the bits 31:16 are used only by VBIOS and not GOP, so that wont 
> help.
> we need to come up with some other method to confirm the value or verify
> if intel gop is loaded. i will get back if i can find such a mechanism.

Oh, that's unfortunate. IIRC we use some other SWF register to check if
something already initialized things in the cdclk sanitation path.
Not sure if the same could be used here.

> >> As mentioned in another thread, this needs to be done for SKL too.
> >> i dont have a SKL system so if no one else can make a patch for it
> >> i will have to share an untested patch for it :).
> > For SKL it seems a bit easier, since it apparently just stores the max
> > cdclk in 10.1 decimal fixed point in bits 10:0. So invalid/uninitialized
> > values would be easier to spot.
> >
> > Hmm. 11 bits and 10.1 fixed point format, I wonder if it's really
> > decimal and not binary fixed point...
> it uses the same value programmed in CDCLK_CTL register.
> i.e 01 0011 0011 1b= 308.57MHz

OK, so binary fixed point. Maybe I should file a bug against bspec to
remove this confusing "decimal" naming scheme from the cdclk stuff...

> 
> regards,
> Sivakumar
> >>>drivers/gpu/drm/i915/intel_display.c | 60 
> >>> 
> >>>1 file changed, 47 insertions(+), 13 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> >>> b/drivers/gpu/drm/i915/intel_display.c
> >>> index 836bbdc239b6..1d70f6bf2934 100644
> >>> --- a/drivers/gpu/drm/i915/intel_display.c
> >>> +++ b/drivers/gpu/drm/i915/intel_display.c
> >>> @@ -5407,21 +5407,55 @@ static void intel_update_max_cdclk(struct 
> >>> drm_device *dev)
> >>>   dev_priv->max_cdclk_freq = 45;
> >>>   else
> >>>   dev_priv->max_cdclk_freq = 

Re: [Intel-gfx] [PATCH v2] drm/i915: Avoid selecting unavailable BSD2 ring

[Tvrtko Ursulin]

Hi,

On 23/02/16 10:52, Gabriel Feceoru wrote:

Return error when I915_EXEC_BSD_RING2 flag is set but BSD2 ring
is not available in the HW.


What is the reasoning behind this? So far kernel was allowing userspace 
to select these bits and execute on the first engine. With this patch it 
would start failing potentially breaking userspace. Is it not too late 
to make such change?


Regards,

Tvrtko


v2: Reworked
Signed-off-by: Gabriel Feceoru 
---
  drivers/gpu/drm/i915/i915_gem_execbuffer.c | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 8fd00d2..9fbd023 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1394,6 +1394,13 @@ eb_select_ring(struct drm_i915_private *dev_priv,
return -EINVAL;
}

+   if ((user_ring_id == I915_EXEC_BSD) && !HAS_BSD2(dev_priv) &&
+   ((args->flags & I915_EXEC_BSD_MASK) != 0)) {
+   DRM_DEBUG("execbuf with bsd ring but with invalid "
+ "bsd dispatch flags: %d\n", (int)(args->flags));
+   return -EINVAL;
+   }
+
if (user_ring_id == I915_EXEC_BSD && HAS_BSD2(dev_priv)) {
unsigned int bsd_idx = args->flags & I915_EXEC_BSD_MASK;



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

[Intel-gfx] ✗ Fi.CI.BAT: failure for Reorganise calls to vmap() GEM objects

[Patchwork]

== Series Details ==

Series: Reorganise calls to vmap() GEM objects
URL   : https://patchwork.freedesktop.org/series/3688/
State : failure

== Summary ==

Series 3688v1 Reorganise calls to vmap() GEM objects
http://patchwork.freedesktop.org/api/1.0/series/3688/revisions/1/mbox/

Test gem_cs_prefetch:
Subgroup basic-default:
incomplete -> PASS   (ilk-hp8440p)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass   -> DMESG-WARN (ilk-hp8440p) UNSTABLE
Test kms_force_connector_basic:
Subgroup force-edid:
skip   -> PASS   (snb-x220t)
Subgroup force-load-detect:
dmesg-fail -> FAIL   (snb-x220t)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (skl-i5k-2) UNSTABLE
Subgroup suspend-read-crc-pipe-c:
pass   -> DMESG-WARN (skl-i5k-2) UNSTABLE
Test pm_rpm:
Subgroup basic-pci-d3-state:
pass   -> DMESG-WARN (byt-nuc)
Subgroup basic-rte:
pass   -> DMESG-WARN (bsw-nuc-2)
pass   -> FAIL   (hsw-gt2)
dmesg-warn -> PASS   (byt-nuc) UNSTABLE

bsw-nuc-2total:168  pass:136  dwarn:1   dfail:0   fail:1   skip:30 
byt-nuc  total:168  pass:142  dwarn:1   dfail:0   fail:0   skip:25 
hsw-gt2  total:168  pass:156  dwarn:0   dfail:1   fail:1   skip:10 
ilk-hp8440p  total:168  pass:117  dwarn:1   dfail:0   fail:1   skip:49 
ivb-t430stotal:168  pass:153  dwarn:0   dfail:0   fail:1   skip:14 
skl-i5k-2total:168  pass:151  dwarn:1   dfail:0   fail:0   skip:16 
snb-dellxps  total:168  pass:145  dwarn:0   dfail:1   fail:0   skip:22 
snb-x220ttotal:168  pass:145  dwarn:0   dfail:0   fail:2   skip:21 

Results at /archive/results/CI_IGT_test/Patchwork_1457/

08fc1b101049694778bff7559e1d05250d2e7072 drm-intel-nightly: 
2016y-02m-22d-17h-30m-27s UTC integration manifest
2cd6b67de5e461e31cac718dc8cd4320162ab95c drm/i915: optimise 
i915_gem_object_vmap_range() for small objects
2c70e45577cbd3f1a8646219674bb1e0953c2d93 drm/i915: refactor duplicate object 
vmap functions (reworked)
4061b03c5ebdf6db460b11b4f4afe7fcfe4619eb drm/i915: add 
i915_gem_object_vmap_range() to map GEM object to virtual space

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for Possible 4.5 i915 Skylake regression

[Patchwork]

== Series Details ==

Series: Possible 4.5 i915 Skylake regression
URL   : https://patchwork.freedesktop.org/series/3713/
State : failure

== Summary ==

Series 3713v1 Possible 4.5 i915 Skylake regression
http://patchwork.freedesktop.org/api/1.0/series/3713/revisions/1/mbox/

Test gem_cs_prefetch:
Subgroup basic-default:
incomplete -> PASS   (ilk-hp8440p)
Test gem_sync:
Subgroup basic-bsd:
pass   -> DMESG-FAIL (ilk-hp8440p)
Test kms_force_connector_basic:
Subgroup force-edid:
skip   -> PASS   (snb-x220t)
Subgroup force-load-detect:
dmesg-fail -> FAIL   (snb-dellxps)
fail   -> DMESG-FAIL (ivb-t430s)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (skl-i5k-2) UNSTABLE
pass   -> DMESG-WARN (snb-x220t)
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (skl-i5k-2) UNSTABLE
Test pm_rpm:
Subgroup basic-rte:
pass   -> DMESG-WARN (bsw-nuc-2)

bdw-nuci7total:165  pass:154  dwarn:0   dfail:0   fail:0   skip:11 
bdw-ultratotal:168  pass:154  dwarn:0   dfail:0   fail:0   skip:14 
bsw-nuc-2total:168  pass:136  dwarn:1   dfail:0   fail:1   skip:30 
byt-nuc  total:168  pass:142  dwarn:1   dfail:0   fail:0   skip:25 
hsw-gt2  total:168  pass:157  dwarn:0   dfail:1   fail:0   skip:10 
ilk-hp8440p  total:168  pass:117  dwarn:0   dfail:1   fail:1   skip:49 
ivb-t430stotal:168  pass:153  dwarn:0   dfail:1   fail:0   skip:14 
skl-i5k-2total:168  pass:151  dwarn:1   dfail:0   fail:0   skip:16 
snb-dellxps  total:168  pass:145  dwarn:0   dfail:0   fail:1   skip:22 
snb-x220ttotal:168  pass:144  dwarn:1   dfail:1   fail:1   skip:21 

Results at /archive/results/CI_IGT_test/Patchwork_1459/

08fc1b101049694778bff7559e1d05250d2e7072 drm-intel-nightly: 
2016y-02m-22d-17h-30m-27s UTC integration manifest
a85601ae9c2b9517866c8fa7fa20d0bcf108777f Possible 4.5 i915 Skylake regression

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Change WARN_ON(!wm_changed) to I915_STATE_WARN_ON()

[Patchwork]

== Series Details ==

Series: drm/i915: Change WARN_ON(!wm_changed) to I915_STATE_WARN_ON()
URL   : https://patchwork.freedesktop.org/series/3698/
State : failure

== Summary ==

Series 3698v1 drm/i915: Change WARN_ON(!wm_changed) to I915_STATE_WARN_ON()
http://patchwork.freedesktop.org/api/1.0/series/3698/revisions/1/mbox/

Test drv_getparams_basic:
Subgroup basic-eu-total:
pass   -> INCOMPLETE (ilk-hp8440p)
Test drv_module_reload_basic:
pass   -> INCOMPLETE (ilk-hp8440p)
Test gem_basic:
Subgroup create-close:
pass   -> INCOMPLETE (ilk-hp8440p)
Test gem_cs_prefetch:
Subgroup basic-default:
incomplete -> PASS   (ilk-hp8440p)
Test gem_cs_tlb:
Subgroup basic-default:
pass   -> INCOMPLETE (ilk-hp8440p)
Test gem_ctx_basic:
skip   -> INCOMPLETE (ilk-hp8440p)
Test gem_ctx_exec:
Subgroup basic:
skip   -> INCOMPLETE (ilk-hp8440p)
Test gem_ctx_param_basic:
Subgroup basic:
skip   -> INCOMPLETE (ilk-hp8440p)
Subgroup invalid-param-set:
skip   -> INCOMPLETE (ilk-hp8440p)
Subgroup non-root-set-no-zeromap:
skip   -> INCOMPLETE (ilk-hp8440p)
Test gem_exec_basic:
Subgroup basic-blt:
skip   -> INCOMPLETE (ilk-hp8440p)
Test gem_flink_basic:
Subgroup bad-open:
pass   -> INCOMPLETE (ilk-hp8440p)
Subgroup flink-lifetime:
pass   -> INCOMPLETE (ilk-hp8440p)
Test gem_mmap:
Subgroup basic:
pass   -> INCOMPLETE (ilk-hp8440p)
Subgroup basic-small-bo:
pass   -> INCOMPLETE (ilk-hp8440p)
Test gem_mmap_gtt:
Subgroup basic-copy:
pass   -> INCOMPLETE (ilk-hp8440p)
Subgroup basic-read:
pass   -> INCOMPLETE (ilk-hp8440p)
Subgroup basic-read-write:
pass   -> INCOMPLETE (ilk-hp8440p)
Subgroup basic-read-write-distinct:
pass   -> INCOMPLETE (ilk-hp8440p)
Subgroup basic-short:
pass   -> INCOMPLETE (ilk-hp8440p)
Subgroup basic-small-bo-tiledy:
pass   -> INCOMPLETE (ilk-hp8440p)
Subgroup basic-small-copy:
pass   -> INCOMPLETE (ilk-hp8440p)
Subgroup basic-small-copy-xy:
pass   -> INCOMPLETE (ilk-hp8440p)
Subgroup basic-write:
pass   -> INCOMPLETE (ilk-hp8440p)
Subgroup basic-write-cpu-read-gtt:
skip   -> INCOMPLETE (ilk-hp8440p)
Subgroup basic-write-gtt-no-prefault:
pass   -> INCOMPLETE (ilk-hp8440p)
Test gem_pread:
Subgroup basic:
pass   -> INCOMPLETE (ilk-hp8440p)
Test gem_pwrite:
Subgroup basic:
pass   -> INCOMPLETE (ilk-hp8440p)
Test gem_ringfill:
Subgroup basic-default-bomb:
pass   -> INCOMPLETE (ilk-hp8440p)
Subgroup basic-default-child:
pass   -> INCOMPLETE (ilk-hp8440p)
Test gem_storedw_loop:
Subgroup basic-blt:
skip   -> INCOMPLETE (ilk-hp8440p)
Subgroup basic-bsd:
skip   -> INCOMPLETE (ilk-hp8440p)
Subgroup basic-bsd2:
skip   -> INCOMPLETE (ilk-hp8440p)
Subgroup basic-vebox:
skip   -> INCOMPLETE (ilk-hp8440p)
Test gem_sync:
Subgroup basic-blt:
skip   -> INCOMPLETE (ilk-hp8440p)
Subgroup basic-bsd:
pass   -> INCOMPLETE (ilk-hp8440p)
Subgroup basic-bsd1:
skip   -> INCOMPLETE (ilk-hp8440p)
Subgroup basic-default:
pass   -> INCOMPLETE (ilk-hp8440p)
Subgroup basic-render:
pass   -> INCOMPLETE (ilk-hp8440p)
Subgroup basic-vebox:
skip   -> INCOMPLETE (ilk-hp8440p)
Test gem_tiled_pread_basic:
pass   -> INCOMPLETE (ilk-hp8440p)
Test kms_addfb_basic:
Subgroup addfb25-bad-modifier:
pass   -> INCOMPLETE (ilk-hp8440p)
Subgroup addfb25-modifier-no-flag:
pass   -> INCOMPLETE (ilk-hp8440p)
Subgroup addfb25-x-tiled:
pass   -> INCOMPLETE (ilk-hp8440p)
Subgroup addfb25-y-tiled:
pass   -> INCOMPLETE (ilk-hp8440p)
Subgroup bad-pitch-0:
pass   -> INCOMPLETE (ilk-hp8440p)
Subgroup bad-pitch-1024:
pass   -> INCOMPLETE (ilk-hp8440p)
Subgroup bad-pitch-128:
pass   -> INCOMPLETE (ilk-hp8440p)
Subgroup bad-pitch-65536:
pass   -> INCOMPLETE (ilk-hp8440p)
Subgroup basic:
pass   -> INCOMPLETE (ilk-hp8440p)

Re: [Intel-gfx] [PATCH] drm/i915: Use SWF06 to figure out max cdclk for BDW

[Thulasimani, Sivakumar]

On 2/16/2016 3:35 PM, Ville Syrjälä wrote:

On Tue, Feb 16, 2016 at 07:13:05AM +0530, Thulasimani, Sivakumar wrote:


On 2/12/2016 8:36 PM, ville.syrj...@linux.intel.com wrote:

From: Ville Syrjälä 

Bspec tells us that we can allow cdclk up to 540Mhz on BDW ULX, or
up to 675 MHz on ULT, bu only if extra cooling is provided. There
don't seem to be any strap or VBT bits to tells us this however.

But I did spot something potentially relevant in
VBIOS_GOP_Driver_SWF_Registers.pdf. Apparently VBIOS/GOP can pass
the max cdclk frequeny in SWF06 to the driver. Let's assume the firmware
knows what its doing and trust the max cdclk in SWF06 if it's higher
than the basic limit specified in Bspec. To avoid regressing anything
let's ignore SWF06 if it indicates a lower limit than Bspec.

Cc: Clint Taylor 
Cc: "Thulasimani, Sivakumar" 
Signed-off-by: Ville Syrjälä 
---

I'm not at all sure if this is the right way to go about it. Sivakumar,
since you seem to have some ideas on this maybe you can have a look.
I'm not aware of any complaints so far that people can't get the cdclk
as high is they should on specific machines, so not sure if this is really
even needed.

The other open question is what we should do if the VBIOS limit is
lower than what we'd expect based on BSpec. Should we still trust it?
Sadly we can't verify the SWF06 cdclk value in any way since it
only has two bits and we have four possible cdclk values.

The value stored in SWF06 is the CD Clock VBIOS/GOP sees during boot. so
it just backs up the CD Clock before it optimizes for the available LFP.
if we
are trusting for higher value we should trust it for lower value too.
The OEM might have did this to either reduce max resolution for cheaper
products or might have removed some cooling mechanisms for thinner
designs since we cannot say which of the reasons we should trust the
lower value too.

now comes to tough part :(, this SWF06 is saved by VBIOS/GOP driver
from intel alone(it is not programmed from VBT),
since GOP driver can be implemented by anyone and
if anyone implements their own GOP driver we cannot be sure if the
value is valid or not. please check if we can check for "Intel GOP driver".
And if "Intel GOP driver" was used during boot, we can trust the value
100%.  i am not sure how this can be done, so i would recommend
trusting the values with clear debug messages as done below already.

We definitely need a way to validate the register value before we trust
it for lower values. I suppose we might be able to look at bits 31:16
since those should store the current cdclk "decimal" value. If that part
looks reasonable, we might be able to trust the "max cdclk" bits as well.
it seems the bits 31:16 are used only by VBIOS and not GOP, so that wont 
help.

we need to come up with some other method to confirm the value or verify
if intel gop is loaded. i will get back if i can find such a mechanism.

As mentioned in another thread, this needs to be done for SKL too.
i dont have a SKL system so if no one else can make a patch for it
i will have to share an untested patch for it :).

For SKL it seems a bit easier, since it apparently just stores the max
cdclk in 10.1 decimal fixed point in bits 10:0. So invalid/uninitialized
values would be easier to spot.

Hmm. 11 bits and 10.1 fixed point format, I wonder if it's really
decimal and not binary fixed point...

it uses the same value programmed in CDCLK_CTL register.
i.e 01 0011 0011 1b= 308.57MHz

regards,
Sivakumar

   drivers/gpu/drm/i915/intel_display.c | 60 

   1 file changed, 47 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 836bbdc239b6..1d70f6bf2934 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5407,21 +5407,55 @@ static void intel_update_max_cdclk(struct drm_device 
*dev)
dev_priv->max_cdclk_freq = 45;
else
dev_priv->max_cdclk_freq = 337500;
-   } else if (IS_BROADWELL(dev))  {
+   } else if (IS_BROADWELL(dev)) {
+   int bios_max_cdclk_freq, max_cdclk_freq;
+
/*
-* FIXME with extra cooling we can allow
-* 540 MHz for ULX and 675 Mhz for ULT.
-* How can we know if extra cooling is
-* available? PCI ID, VTB, something else?
+* With extra cooling we can allow 540 MHz for
+* ULX and 675 Mhz for ULT. Assume VBIOS/GOP
+* passes that information in SWF06.
 */
-   if (I915_READ(FUSE_STRAP) & HSW_CDCLK_LIMIT)
-   dev_priv->max_cdclk_freq = 45;
-   else if (IS_BDW_ULX(dev))
-   dev_priv->max_cdclk_freq = 45;
- 

[Intel-gfx] [PATCH v2] drm/i915: Avoid selecting unavailable BSD2 ring

[Gabriel Feceoru]

Return error when I915_EXEC_BSD_RING2 flag is set but BSD2 ring
is not available in the HW.

v2: Reworked
Signed-off-by: Gabriel Feceoru 
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 8fd00d2..9fbd023 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1394,6 +1394,13 @@ eb_select_ring(struct drm_i915_private *dev_priv,
return -EINVAL;
}
 
+   if ((user_ring_id == I915_EXEC_BSD) && !HAS_BSD2(dev_priv) &&
+   ((args->flags & I915_EXEC_BSD_MASK) != 0)) {
+   DRM_DEBUG("execbuf with bsd ring but with invalid "
+ "bsd dispatch flags: %d\n", (int)(args->flags));
+   return -EINVAL;
+   }
+
if (user_ring_id == I915_EXEC_BSD && HAS_BSD2(dev_priv)) {
unsigned int bsd_idx = args->flags & I915_EXEC_BSD_MASK;
 
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH 2/5] drm/i915: Do not read GAMMA_MODE register

[Lionel Landwerlin]

On 23/02/16 00:38, Matt Roper wrote:

On Mon, Feb 22, 2016 at 02:18:08PM +, Lionel Landwerlin wrote:

Implement Daniel Stone's recommendation to not read registers to infer
the hardware's state.

Signed-off-by: Lionel Landwerlin 

Do we need to ensure that software and hardware state are synchronized
at startup?  A boot firmware might have set it to something different
before our driver starts up; if we use 'fastboot' then we might not do
any modesets and might wind up with 0 (8BIT) in our state variable, but
something else actually programmed into the hardware.


Matt


Thanks Matt,

It makes sense know, I couldn't understand why this would ever be at 
something different that 8bit mode...
I guess the value should be read from the intel_color_init() function 
upon startup.


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

Re: [Intel-gfx] [PATCH v4 2/3] drm/i915: refactor duplicate object vmap functions (reworked)

[Tvrtko Ursulin]

On 23/02/16 10:06, Chris Wilson wrote:

On Mon, Feb 22, 2016 at 04:06:39PM +, Tvrtko Ursulin wrote:


[Cc Chris as the author of the idea.]

Hi,

On 22/02/16 15:18, Dave Gordon wrote:

This is essentially Chris Wilson's patch of a similar name, reworked on
top of Alex Dai's recent patch:
   drm/i915: Add i915_gem_object_vmap to map GEM object to virtual space
Chris' original commentary said:

   We now have two implementations for vmapping a whole object, one for
   dma-buf and one for the ringbuffer. If we couple the vmapping into
   the obj->pages lifetime, then we can reuse an obj->vmapping for both
   and at the same time couple it into the shrinker.


As a general concept my worry is that by implementing this approach
we tie two unrelated concepts together.

Shrinker is about backing storage (used/free pages in a machine),
while vmap is about kernel address space. And then on 32-bit with
its limited vmap space (128MiB, right?), it can become exhausted
much sooner that the shrinker would be triggered. And we would rely
on the shrinker running to free up address space as well now, right?


Yes, we use the shrinker to free address space.


So unless I am missing something that doesn't fit well.


The opposite. Even more reason for the shrinker to be able to recover
vmap space on 32bit systems (for external users, not just ourselves).


How? I don't see that failed vmapping will trigger shrinking. What will 
prevent i915 from accumulating objects with vmaps sticking around for 
too long potentially?



diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 434a452..47f186e 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -2056,7 +2056,7 @@ static int init_phys_status_page(struct intel_engine_cs 
*ring)
  void intel_unpin_ringbuffer_obj(struct intel_ringbuffer *ringbuf)
  {
if (HAS_LLC(ringbuf->obj->base.dev) && !ringbuf->obj->stolen)
-   vunmap(ringbuf->virtual_start);
+   i915_gem_object_unpin_vmap(ringbuf->obj);
else
iounmap(ringbuf->virtual_start);
ringbuf->virtual_start = NULL;
@@ -2077,16 +2077,14 @@ int intel_pin_and_map_ringbuffer_obj(struct drm_device 
*dev,
return ret;

ret = i915_gem_object_set_to_cpu_domain(obj, true);
-   if (ret) {
-   i915_gem_object_ggtt_unpin(obj);
-   return ret;
-   }
+   if (ret)
+   goto unpin;

-   ringbuf->virtual_start = i915_gem_object_vmap_range(obj, 0,
-   ringbuf->size >> PAGE_SHIFT);
-   if (ringbuf->virtual_start == NULL) {
-   i915_gem_object_ggtt_unpin(obj);
-   return -ENOMEM;
+   ringbuf->virtual_start = i915_gem_object_pin_vmap(obj);
+   if (IS_ERR(ringbuf->virtual_start)) {
+   ret = PTR_ERR(ringbuf->virtual_start);
+   ringbuf->virtual_start = NULL;
+   goto unpin;
}
} else {
ret = i915_gem_obj_ggtt_pin(obj, PAGE_SIZE, PIN_MAPPABLE);
@@ -2094,10 +2092,8 @@ int intel_pin_and_map_ringbuffer_obj(struct drm_device 
*dev,
return ret;

ret = i915_gem_object_set_to_gtt_domain(obj, true);
-   if (ret) {
-   i915_gem_object_ggtt_unpin(obj);
-   return ret;
-   }
+   if (ret)
+   goto unpin;

/* Access through the GTT requires the device to be awake. */
assert_rpm_wakelock_held(dev_priv);
@@ -2105,14 +2101,18 @@ int intel_pin_and_map_ringbuffer_obj(struct drm_device 
*dev,
ringbuf->virtual_start = ioremap_wc(dev_priv->gtt.mappable_base 
+
i915_gem_obj_ggtt_offset(obj), 
ringbuf->size);
if (ringbuf->virtual_start == NULL) {
-   i915_gem_object_ggtt_unpin(obj);
-   return -EINVAL;
+   ret = -ENOMEM;
+   goto unpin;


Another refactoring not really belonging to this patch. I am not
sure it is that good to share the cleanup path from the two
logically split branches. May be fragile in the future. But it is
short enough so OK.

But as a related question, I wonder why doesn't the LRC require the
same !HAS_LLC approach when mapping as ring buffer does here?


We don't try to use stolen for LRC. The main difficulty lies in
deciding how to map the state object, stolen forces us to use an
ioremapping through the GTT and so only suitable for write-only
mappings. However, we could be using the per-context HWS, for which we
want a CPU accessible, direct pointer.


I wasn't asking about stolen but the !HAS_LLC path. Even 

[Intel-gfx] [PATCH RESEND FOR CI] drm/i915/gen9: Set value of Indirect Context Offset based on gen version

[Michel Thierry]

The cache line offset for the Indirect CS context (0x21C8) varies from gen
to gen.

v2: Move it into a function (Arun), use MISSING_CASE (Chris)
v3: Rebased (catched by ci bat)

Cc: Arun Siluvery 
Cc: Chris Wilson 
Reviewed-by: Arun Siluvery 
Signed-off-by: Michel Thierry 
---
 drivers/gpu/drm/i915/intel_lrc.c | 26 --
 1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 2dca5e1..e12fcab 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -223,7 +223,8 @@ enum {
FAULT_AND_CONTINUE /* Unsupported */
 };
 #define GEN8_CTX_ID_SHIFT 32
-#define CTX_RCS_INDIRECT_CTX_OFFSET_DEFAULT  0x17
+#define GEN8_CTX_RCS_INDIRECT_CTX_OFFSET_DEFAULT   0x17
+#define GEN9_CTX_RCS_INDIRECT_CTX_OFFSET_DEFAULT   0x26
 
 static int intel_lr_context_pin(struct intel_context *ctx,
struct intel_engine_cs *engine);
@@ -2317,6 +2318,27 @@ make_rpcs(struct drm_device *dev)
return rpcs;
 }
 
+static u32 intel_lr_indirect_ctx_offset(struct intel_engine_cs *ring)
+{
+   u32 indirect_ctx_offset;
+
+   switch (INTEL_INFO(ring->dev)->gen) {
+   default:
+   MISSING_CASE(INTEL_INFO(ring->dev)->gen);
+   /* fall through */
+   case 9:
+   indirect_ctx_offset =
+   GEN9_CTX_RCS_INDIRECT_CTX_OFFSET_DEFAULT;
+   break;
+   case 8:
+   indirect_ctx_offset =
+   GEN8_CTX_RCS_INDIRECT_CTX_OFFSET_DEFAULT;
+   break;
+   }
+
+   return indirect_ctx_offset;
+}
+
 static int
 populate_lr_context(struct intel_context *ctx, struct drm_i915_gem_object 
*ctx_obj,
struct intel_engine_cs *ring, struct intel_ringbuffer 
*ringbuf)
@@ -2389,7 +2411,7 @@ populate_lr_context(struct intel_context *ctx, struct 
drm_i915_gem_object *ctx_o
(wa_ctx->indirect_ctx.size / CACHELINE_DWORDS);
 
reg_state[CTX_RCS_INDIRECT_CTX_OFFSET+1] =
-   CTX_RCS_INDIRECT_CTX_OFFSET_DEFAULT << 6;
+   intel_lr_indirect_ctx_offset(ring) << 6;
 
reg_state[CTX_BB_PER_CTX_PTR+1] =
(ggtt_offset + wa_ctx->per_ctx.offset * 
sizeof(uint32_t)) |
-- 
2.7.1

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

Re: [Intel-gfx] [PATCH 136/190] drm/i915: Move ioremap_wc tracking onto VMA

[Chris Wilson]

On Mon, Feb 22, 2016 at 03:29:57PM +, Tvrtko Ursulin wrote:
> 
> On 19/02/16 15:11, Chris Wilson wrote:
> >On Thu, Feb 11, 2016 at 02:10:19PM +, Tvrtko Ursulin wrote:
> >>
> >>On 11/02/16 13:29, Chris Wilson wrote:
> >>>On Thu, Feb 11, 2016 at 01:20:46PM +, Tvrtko Ursulin wrote:
> 
> 
> On 11/01/16 10:45, Chris Wilson wrote:
> >By tracking the iomapping on the VMA itself, we can share that area
> >between multiple users. Also by only revoking the iomapping upon
> >unbinding from the mappable portion of the GGTT, we can keep that iomap
> >across multiple invocations (e.g. execlists context pinning).
> 
> Between the lines and from some IRC discussion it seems the goal of
> this is to fix an address space memory leak with fbcon?
> >>>
> >>>The goal is to prevent an issue from hastily dropping iomappings (and
> >>>vmappings elsewhere) when unpinning contexts. That comes into play when
> >>>we track the ring->vma (not just track ring->vma as we do now, but can
> >>>rely on the vma being persistent). Fixing a leak on driver unload is an
> >>>interesting side-effect.
> >>>
> But I don't know fbdev so can't find who would do the unpin on the
> VMA to allow unbind to eventually unmap it?
> >>>
> >>>That actually gets fixed in another patch when we teach intel_fbdev to
> >>>actually track the VMA it allocates, as right now we deliberately leak
> >>>it to keep the code simple.
> >>
> >>Ok in that case ack on the patch.
> >>
> >>It will need to assert on VMA being pinned I think and some minor
> >>changes when you rebase it on top of nightly as standalone so I can
> >>properly review it then.
> >
> >Had some more fun recently where the iomap was showing up again, and
> >realised that for 64b systems we can keep a pointer to inside our
> >dev_priv->gtt.mappable iomapping. Makes the patch a little more ugly
> >(requires #ifdeffry) but eliminates all of the runtime iomapping
> >overhead!
> >
> >However, that wasn't enough for the test case as the limitation to the
> >mappable aperture was too severe...
> 
> Could use kmap then and not go through the aperture? I had a patch
> of similar semantics to your vma->iomap somewhere which, to start
> with, adds ability to kmap one page. Or it could do the whole
> objects for simplicity which for LRCs should be OK.

Actually I used vmap to avoid the limitation. But yes, for LRC we really
don't need to keep the whole state object mapped (and we don't, we just
kmap the registers), but we would either want to reduce the ringbuffer to
a single page, avoid commands spanning the page boundaries, or just use
vmap.
-Chris

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

Re: [Intel-gfx] [PATCH v4 3/3] drm/i915: optimise i915_gem_object_vmap_range() for small objects

[Chris Wilson]

On Mon, Feb 22, 2016 at 03:18:28PM +, Dave Gordon wrote:
> Now that we use this function for ringbuffers and other "small" objects,
> it's worth avoiding an extra kmalloc()/kfree() cycle if the page array
> is small enough to put on the stack. Here we've chosen an arbitrary
> cutoff of 32 (4k) pages, which is big enough for a ringbuffer (4 pages)
> or a context image (currently up to 22 pages).
> 
> Signed-off-by: Dave Gordon 
> Cc: Tvrtko Ursulin 
> Cc: Alex Dai 
> Cc: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/i915_gem.c | 18 +-
>  1 file changed, 13 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 14942cf..effb69b 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2422,6 +2422,7 @@ void *i915_gem_object_vmap_range(struct 
> drm_i915_gem_object *obj,
>unsigned int npages)
>  {
>   struct sg_page_iter sg_iter;
> + struct page *mypages[32];

Use stack or stack_pages, that's the pattern we've used elsewhere.
Though pages_on_stack would be more in line with the rest of the kernel.

>   struct page **pages;
>   void *addr;
>   int i;
> @@ -2431,10 +2432,16 @@ void *i915_gem_object_vmap_range(struct 
> drm_i915_gem_object *obj,
>   return NULL;
>   }
>  
> - pages = drm_malloc_ab(npages, sizeof(*pages));
> - if (pages == NULL) {
> - DRM_DEBUG_DRIVER("Failed to get space for pages\n");
> - return NULL;
> + if (npages <= ARRAY_SIZE(mypages))
> + pages = mypages;

If one branch requires braces, add them to all.

> + else {
> + pages = kmalloc(npages*sizeof(*pages), GFP_TEMPORARY | 
> __GFP_NOWARN);

drm_malloc_gfp

Otherwise, seems an ok idea. The deepest vmap is the
ioctl/execbuffer/cmdparser to which using a further 256 bytes of stack is
acceptable.
-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 libdrm] intel/skl: Add missing SKL PCI IDs

[Lionel Landwerlin]

On 17/02/16 10:40, Michał Winiarski wrote:

Used by production devices:
 Intel(R) HD Graphics 510
 Intel(R) HD Graphics 535
 Intel(R) Iris(TM) Graphics 550
 Intel(R) Iris(TM) Graphics P555

Signed-off-by: Michał Winiarski 


Tested-by: Lionel Landwerlin 

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

Re: [Intel-gfx] [PATCH v4 2/3] drm/i915: refactor duplicate object vmap functions (reworked)

[Chris Wilson]

On Mon, Feb 22, 2016 at 04:06:39PM +, Tvrtko Ursulin wrote:
> 
> [Cc Chris as the author of the idea.]
> 
> Hi,
> 
> On 22/02/16 15:18, Dave Gordon wrote:
> >This is essentially Chris Wilson's patch of a similar name, reworked on
> >top of Alex Dai's recent patch:
> >   drm/i915: Add i915_gem_object_vmap to map GEM object to virtual space
> >Chris' original commentary said:
> >
> >   We now have two implementations for vmapping a whole object, one for
> >   dma-buf and one for the ringbuffer. If we couple the vmapping into
> >   the obj->pages lifetime, then we can reuse an obj->vmapping for both
> >   and at the same time couple it into the shrinker.
> 
> As a general concept my worry is that by implementing this approach
> we tie two unrelated concepts together.
> 
> Shrinker is about backing storage (used/free pages in a machine),
> while vmap is about kernel address space. And then on 32-bit with
> its limited vmap space (128MiB, right?), it can become exhausted
> much sooner that the shrinker would be triggered. And we would rely
> on the shrinker running to free up address space as well now, right?

Yes, we use the shrinker to free address space.
 
> So unless I am missing something that doesn't fit well.

The opposite. Even more reason for the shrinker to be able to recover
vmap space on 32bit systems (for external users, not just ourselves).

> >diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
> >b/drivers/gpu/drm/i915/intel_ringbuffer.c
> >index 434a452..47f186e 100644
> >--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> >+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> >@@ -2056,7 +2056,7 @@ static int init_phys_status_page(struct 
> >intel_engine_cs *ring)
> >  void intel_unpin_ringbuffer_obj(struct intel_ringbuffer *ringbuf)
> >  {
> > if (HAS_LLC(ringbuf->obj->base.dev) && !ringbuf->obj->stolen)
> >-vunmap(ringbuf->virtual_start);
> >+i915_gem_object_unpin_vmap(ringbuf->obj);
> > else
> > iounmap(ringbuf->virtual_start);
> > ringbuf->virtual_start = NULL;
> >@@ -2077,16 +2077,14 @@ int intel_pin_and_map_ringbuffer_obj(struct 
> >drm_device *dev,
> > return ret;
> >
> > ret = i915_gem_object_set_to_cpu_domain(obj, true);
> >-if (ret) {
> >-i915_gem_object_ggtt_unpin(obj);
> >-return ret;
> >-}
> >+if (ret)
> >+goto unpin;
> >
> >-ringbuf->virtual_start = i915_gem_object_vmap_range(obj, 0,
> >-ringbuf->size >> PAGE_SHIFT);
> >-if (ringbuf->virtual_start == NULL) {
> >-i915_gem_object_ggtt_unpin(obj);
> >-return -ENOMEM;
> >+ringbuf->virtual_start = i915_gem_object_pin_vmap(obj);
> >+if (IS_ERR(ringbuf->virtual_start)) {
> >+ret = PTR_ERR(ringbuf->virtual_start);
> >+ringbuf->virtual_start = NULL;
> >+goto unpin;
> > }
> > } else {
> > ret = i915_gem_obj_ggtt_pin(obj, PAGE_SIZE, PIN_MAPPABLE);
> >@@ -2094,10 +2092,8 @@ int intel_pin_and_map_ringbuffer_obj(struct 
> >drm_device *dev,
> > return ret;
> >
> > ret = i915_gem_object_set_to_gtt_domain(obj, true);
> >-if (ret) {
> >-i915_gem_object_ggtt_unpin(obj);
> >-return ret;
> >-}
> >+if (ret)
> >+goto unpin;
> >
> > /* Access through the GTT requires the device to be awake. */
> > assert_rpm_wakelock_held(dev_priv);
> >@@ -2105,14 +2101,18 @@ int intel_pin_and_map_ringbuffer_obj(struct 
> >drm_device *dev,
> > ringbuf->virtual_start = ioremap_wc(dev_priv->gtt.mappable_base 
> > +
> > 
> > i915_gem_obj_ggtt_offset(obj), ringbuf->size);
> > if (ringbuf->virtual_start == NULL) {
> >-i915_gem_object_ggtt_unpin(obj);
> >-return -EINVAL;
> >+ret = -ENOMEM;
> >+goto unpin;
> 
> Another refactoring not really belonging to this patch. I am not
> sure it is that good to share the cleanup path from the two
> logically split branches. May be fragile in the future. But it is
> short enough so OK.
> 
> But as a related question, I wonder why doesn't the LRC require the
> same !HAS_LLC approach when mapping as ring buffer does here?

We don't try to use stolen for LRC. The main difficulty lies in
deciding how to map the state object, stolen forces us to use an
ioremapping through the GTT and so only suitable for write-only
mappings. However, we could be using the per-context HWS, for which we
want a CPU accessible, direct pointer.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list

[Intel-gfx] ✗ Fi.CI.BAT: failure for Possible 4.5 i915 Skylake regression

[Patchwork]

== Series Details ==

Series: Possible 4.5 i915 Skylake regression
URL   : https://patchwork.freedesktop.org/series/3713/
State : failure

== Summary ==

Series 3713v1 Possible 4.5 i915 Skylake regression
http://patchwork.freedesktop.org/api/1.0/series/3713/revisions/1/mbox/

Test core_prop_blob:
Subgroup basic:
incomplete -> PASS   (snb-x220t)
Test drv_getparams_basic:
Subgroup basic-eu-total:
incomplete -> PASS   (snb-x220t)
Test gem_cs_prefetch:
Subgroup basic-default:
incomplete -> PASS   (ilk-hp8440p)
Test gem_ctx_param_basic:
Subgroup basic:
incomplete -> PASS   (snb-x220t)
Subgroup basic-default:
incomplete -> PASS   (snb-x220t)
Subgroup non-root-set:
incomplete -> PASS   (snb-x220t)
Subgroup root-set:
incomplete -> PASS   (snb-x220t)
Subgroup root-set-no-zeromap-disabled:
incomplete -> PASS   (snb-x220t)
Test gem_exec_basic:
Subgroup basic-bsd2:
incomplete -> SKIP   (snb-x220t)
Subgroup basic-default:
incomplete -> PASS   (snb-x220t)
Test gem_exec_parse:
Subgroup basic-rejected:
incomplete -> SKIP   (snb-x220t)
Test gem_flink_basic:
Subgroup bad-flink:
incomplete -> PASS   (snb-x220t)
Subgroup basic:
incomplete -> PASS   (snb-x220t)
Subgroup double-flink:
incomplete -> PASS   (snb-x220t)
Test gem_mmap:
Subgroup basic:
incomplete -> PASS   (snb-x220t)
Test gem_mmap_gtt:
Subgroup basic:
incomplete -> PASS   (snb-x220t)
Subgroup basic-read:
incomplete -> PASS   (snb-x220t)
Subgroup basic-read-write:
incomplete -> PASS   (snb-x220t)
Subgroup basic-small-copy-xy:
incomplete -> PASS   (snb-x220t)
Subgroup basic-write-gtt:
incomplete -> PASS   (snb-x220t)
Subgroup basic-write-read-distinct:
incomplete -> PASS   (snb-x220t)
Test gem_pread:
Subgroup basic:
incomplete -> PASS   (snb-x220t)
Test gem_pwrite:
Subgroup basic:
incomplete -> PASS   (snb-x220t)
Test gem_render_linear_blits:
Subgroup basic:
incomplete -> PASS   (snb-x220t)
Test gem_render_tiled_blits:
Subgroup basic:
incomplete -> PASS   (snb-x220t)
Test gem_ringfill:
Subgroup basic-default-child:
incomplete -> PASS   (snb-x220t)
Subgroup basic-default-interruptible:
incomplete -> PASS   (snb-x220t)
Test gem_storedw_loop:
Subgroup basic-vebox:
incomplete -> SKIP   (snb-x220t)
Test gem_sync:
Subgroup basic-bsd:
incomplete -> PASS   (snb-x220t)
pass   -> DMESG-FAIL (ilk-hp8440p)
Test kms_addfb_basic:
Subgroup addfb25-bad-modifier:
incomplete -> PASS   (snb-x220t)
Subgroup addfb25-modifier-no-flag:
incomplete -> PASS   (snb-x220t)
Subgroup addfb25-y-tiled-small:
incomplete -> SKIP   (snb-x220t)
Subgroup addfb25-yf-tiled:
incomplete -> PASS   (snb-x220t)
Subgroup bad-pitch-0:
incomplete -> PASS   (snb-x220t)
Subgroup basic:
incomplete -> PASS   (snb-x220t)
Subgroup bo-too-small-due-to-tiling:
incomplete -> PASS   (snb-x220t)
Subgroup no-handle:
incomplete -> PASS   (snb-x220t)
Subgroup size-max:
incomplete -> PASS   (snb-x220t)
Subgroup too-high:
incomplete -> PASS   (snb-x220t)
Subgroup unused-handle:
incomplete -> PASS   (snb-x220t)
Subgroup unused-modifier:
incomplete -> PASS   (snb-x220t)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
fail   -> PASS   (snb-x220t)
Test kms_force_connector_basic:
Subgroup force-load-detect:
dmesg-fail -> FAIL   (snb-dellxps)
fail   -> DMESG-FAIL (ivb-t430s)
Test kms_pipe_crc_basic:
Subgroup bad-nb-words-1:
incomplete -> PASS   (snb-x220t)
Subgroup bad-source:
incomplete -> PASS   (snb-x220t)
Subgroup hang-read-crc-pipe-b:
incomplete -> PASS   (snb-x220t)
Subgroup hang-read-crc-pipe-c:
incomplete -> SKIP   (snb-x220t)
Subgroup nonblocking-crc-pipe-a-frame-sequence:
incomplete -> PASS   (snb-x220t)
Subgroup nonblocking-crc-pipe-b-frame-sequence:
   

Re: [Intel-gfx] [PATCH] drm/i915: Avoid divbyzero in modesetting

[Tvrtko Ursulin]

On 23/02/16 08:38, Maarten Lankhorst wrote:
> Op 22-02-16 om 15:27 schreef Tvrtko Ursulin:
>> [   10.062881]  [] skl_update_pipe_wm+0x102/0x8c0 [i915]
>> [   10.062942]  [] skl_update_wm+0xff/0x5f0 [i915]
>> [   10.063027]  [] intel_update_watermarks+0x1e/0x30 [i915]
>> [   10.063087]  [] intel_crtc_disable_noatomic+0xd2/0x150 
>> [i915]
>> [   10.063148]  [] 
>> intel_modeset_setup_hw_state+0xdd2/0xde0 [i915]
>> [   10.063181]  [] intel_modeset_init+0x15a3/0x1950 [i915]
>> [   10.063181]  [] i915_driver_load+0x13c6/0x1720 [i915]
> Do you have a full oops I can use for a commit description?

Sure:

 [ cut here ]
 WARNING: CPU: 1 PID: 295 at drivers/gpu/drm/i915/intel_pm.c:2834 
skl_update_pipe_wm+0x102/0x8c0 [i915]()
 WARN_ON(!config->num_pipes_active)
 Modules linked in: coretemp i915(+) 
x
 CPU: 1 PID: 295 Comm: systemd-udevd Tainted: G U  W   4.5.0-rc4-xx 
#25
 Hardware name: x
   88003777f5a8 813485c2 88003777f5f0
  a0236240 88003777f5e0 81050fce 8800aa42
  8800aba18000 8800aba18000 880037304c00 8800aa42
 Call Trace:
  [] dump_stack+0x67/0x95
  [] warn_slowpath_common+0x9e/0xc0
  [] warn_slowpath_fmt+0x4c/0x50
  [] ? flush_work+0x8e/0x280
  [] ? flush_work+0x5/0x280
  [] skl_update_pipe_wm+0x102/0x8c0 [i915]
  [] skl_update_wm+0xff/0x5f0 [i915]
  [] ? trace_hardirqs_on_caller+0x15e/0x1d0
  [] ? trace_hardirqs_on+0xd/0x10
  [] intel_update_watermarks+0x1e/0x30 [i915]
  [] intel_crtc_disable_noatomic+0xd2/0x150 [i915]
  [] intel_modeset_setup_hw_state+0xdd2/0xde0 [i915]
  [] intel_modeset_init+0x15a3/0x1950 [i915]
  [] i915_driver_load+0x13c6/0x1720 [i915]
  [] ? add_sysfs_fw_map_entry+0x9b/0x9b
  [] drm_dev_register+0x6f/0xb0 [drm]
  [] drm_get_pci_dev+0x10a/0x1d0 [drm]
  [] i915_pci_probe+0x49/0x50 [i915]
  [] pci_device_probe+0x80/0xf0
  [] driver_probe_device+0x1bc/0x3d0
  [] __driver_attach+0x66/0x90
  [] ? driver_probe_device+0x3d0/0x3d0
  [] bus_for_each_dev+0x5b/0xa0
  [] driver_attach+0x1e/0x20
  [] bus_add_driver+0x151/0x270
  [] driver_register+0x8c/0xd0
  [] __pci_register_driver+0x5d/0x60
  [] drm_pci_init+0x58/0xf0 [drm]
  [] ? trace_hardirqs_on+0xd/0x10
  [] ? 0xa02aa000
  [] i915_init+0x94/0x9b [i915]
  [] do_one_initcall+0x113/0x1f0
  [] ? rcu_read_lock_sched_held+0x61/0x90
  [] ? kmem_cache_alloc_trace+0x1cc/0x280
  [] do_init_module+0x60/0x1c8
  [] load_module+0x1ceb/0x2410
  [] ? store_uevent+0x40/0x40
  [] ? kernel_read+0x41/0x60
  [] SYSC_finit_module+0x8d/0xa0
  [] SyS_finit_module+0xe/0x10
  [] entry_SYSCALL_64_fastpath+0x12/0x6f
 ---[ end trace 1149e9ab3695a423 ]---
 [ cut here ]

Regards,

Tvrtko


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

Re: [Intel-gfx] System freeze apparently due to GPU memory exhaustion - why?

[Joonas Lahtinen]

Hi,

On ti, 2016-02-23 at 11:55 +1000, Adam Nielsen wrote:
> Hi all,
> 
> I'm an end user and I'm having problems which I believe are ultimately
> caused by an issue with the Intel kernel driver.
> 
> When I am running programs that use a lot of images (e.g. GIMP, Firefox
> with YouTube and Google Maps) then after a short while my whole machine
> will grind to a halt, to the point where even my audio buffers don't
> get updated so I hear the same 500ms of audio repeated in a loop until
> the system comes back to life again.
> 
> Typically the system will stop responding from anywhere between 30
> seconds to a minute, and usually it returns to service after the kernel
> OOM killer has ended a process - typically Firefox as it uses the most
> system memory.
> 
> Of course it's not a system OOM problem, because the system has 16GB of
> RAM and the problem still happens even if less than 4GB is in use.
> 
> Looking at dmesg, the problem always starts with a message like this:
> 
>   Purging GPU memory, 69632 bytes freed, 48553984 bytes still pinned.
> 
> Since system memory is fine, I can only assume this means that there is
> some limit on the amount of memory the video driver can access, and it
> has reached that limit.
> 
> Here is the top of the backtrace, if it's relevant:
> 
>   Call Trace:
>    [] dump_stack+0x4b/0x72
>    [] dump_header+0x87/0x21e
>    [] ? i915_gem_shrinker_oom+0x1a1/0x200 [i915]
>    [] oom_kill_process+0x34b/0x3b0
>    [] out_of_memory+0x21f/0x490
>    [] __alloc_pages_nodemask+0x8c8/0x960
>    [] alloc_kmem_pages_node+0x7b/0x150
> 
> Can anyone shed any light on what's happening here?  Is there a limit
> to how much video memory the system can access?  I thought that was
> done away with once AGP disappeared but perhaps not.
> 

Can you attach a full dmesg from boot until the problem appears?

Regards, Joonas

> Is there any way to alleviate the problems this issue produces?  It's
> very annoying to be zooming around in Google Maps one moment and then
> dumped back to the console the next because the kernel killed X11.
> 
> My system is an Intel DH87MC w/ i7-4770K, kernel 4.3.3.  Three
> monitors, DVI + HDMI + DisplayPort, total res 4960x1600.
> 
> Many thanks,
> Adam.
> 
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Change WARN_ON(!wm_changed) to I915_STATE_WARN_ON()

[Patchwork]

== Series Details ==

Series: drm/i915: Change WARN_ON(!wm_changed) to I915_STATE_WARN_ON()
URL   : https://patchwork.freedesktop.org/series/3698/
State : failure

== Summary ==

Series 3698v1 drm/i915: Change WARN_ON(!wm_changed) to I915_STATE_WARN_ON()
http://patchwork.freedesktop.org/api/1.0/series/3698/revisions/1/mbox/

Test core_prop_blob:
Subgroup basic:
incomplete -> PASS   (snb-x220t)
Test drv_getparams_basic:
Subgroup basic-eu-total:
incomplete -> PASS   (snb-x220t)
pass   -> INCOMPLETE (ilk-hp8440p)
Test drv_module_reload_basic:
pass   -> INCOMPLETE (ilk-hp8440p)
Test gem_basic:
Subgroup create-close:
pass   -> INCOMPLETE (ilk-hp8440p)
Test gem_cs_prefetch:
Subgroup basic-default:
incomplete -> PASS   (ilk-hp8440p)
Test gem_cs_tlb:
Subgroup basic-default:
pass   -> INCOMPLETE (ilk-hp8440p)
Test gem_ctx_basic:
skip   -> INCOMPLETE (ilk-hp8440p)
Test gem_ctx_exec:
Subgroup basic:
skip   -> INCOMPLETE (ilk-hp8440p)
Test gem_ctx_param_basic:
Subgroup basic:
incomplete -> PASS   (snb-x220t)
skip   -> INCOMPLETE (ilk-hp8440p)
Subgroup basic-default:
incomplete -> PASS   (snb-x220t)
Subgroup invalid-param-set:
skip   -> INCOMPLETE (ilk-hp8440p)
Subgroup non-root-set:
incomplete -> PASS   (snb-x220t)
Subgroup non-root-set-no-zeromap:
skip   -> INCOMPLETE (ilk-hp8440p)
Subgroup root-set:
incomplete -> PASS   (snb-x220t)
Subgroup root-set-no-zeromap-disabled:
incomplete -> PASS   (snb-x220t)
Test gem_exec_basic:
Subgroup basic-blt:
skip   -> INCOMPLETE (ilk-hp8440p)
Subgroup basic-bsd2:
incomplete -> SKIP   (snb-x220t)
Subgroup basic-default:
incomplete -> PASS   (snb-x220t)
Test gem_exec_parse:
Subgroup basic-rejected:
incomplete -> SKIP   (snb-x220t)
Test gem_flink_basic:
Subgroup bad-flink:
incomplete -> PASS   (snb-x220t)
Subgroup bad-open:
pass   -> INCOMPLETE (ilk-hp8440p)
Subgroup basic:
incomplete -> PASS   (snb-x220t)
Subgroup double-flink:
incomplete -> PASS   (snb-x220t)
Subgroup flink-lifetime:
pass   -> INCOMPLETE (ilk-hp8440p)
Test gem_mmap:
Subgroup basic:
incomplete -> PASS   (snb-x220t)
pass   -> INCOMPLETE (ilk-hp8440p)
Subgroup basic-small-bo:
pass   -> INCOMPLETE (ilk-hp8440p)
Test gem_mmap_gtt:
Subgroup basic:
incomplete -> PASS   (snb-x220t)
Subgroup basic-copy:
pass   -> INCOMPLETE (ilk-hp8440p)
Subgroup basic-read:
incomplete -> PASS   (snb-x220t)
pass   -> INCOMPLETE (ilk-hp8440p)
Subgroup basic-read-write:
incomplete -> PASS   (snb-x220t)
pass   -> INCOMPLETE (ilk-hp8440p)
Subgroup basic-read-write-distinct:
pass   -> INCOMPLETE (ilk-hp8440p)
Subgroup basic-short:
pass   -> INCOMPLETE (ilk-hp8440p)
Subgroup basic-small-bo-tiledy:
pass   -> INCOMPLETE (ilk-hp8440p)
Subgroup basic-small-copy:
pass   -> INCOMPLETE (ilk-hp8440p)
Subgroup basic-small-copy-xy:
incomplete -> PASS   (snb-x220t)
pass   -> INCOMPLETE (ilk-hp8440p)
Subgroup basic-write:
pass   -> INCOMPLETE (ilk-hp8440p)
Subgroup basic-write-cpu-read-gtt:
skip   -> INCOMPLETE (ilk-hp8440p)
Subgroup basic-write-gtt:
incomplete -> PASS   (snb-x220t)
Subgroup basic-write-gtt-no-prefault:
pass   -> INCOMPLETE (ilk-hp8440p)
Subgroup basic-write-read-distinct:
incomplete -> PASS   (snb-x220t)
Test gem_pread:
Subgroup basic:
incomplete -> PASS   (snb-x220t)
pass   -> INCOMPLETE (ilk-hp8440p)
Test gem_pwrite:
Subgroup basic:
incomplete -> PASS   (snb-x220t)
pass   -> INCOMPLETE (ilk-hp8440p)
Test gem_render_linear_blits:
Subgroup basic:
incomplete -> PASS   (snb-x220t)
Test gem_render_tiled_blits:
Subgroup basic:
incomplete -> PASS   (snb-x220t)
Test gem_ringfill:
Subgroup basic-default-bomb:
pass   -> INCOMPLETE (ilk-hp8440p)
Subgroup 

[Intel-gfx] ✗ Fi.CI.BAT: failure for Reorganise calls to vmap() GEM objects

[Patchwork]

== Series Details ==

Series: Reorganise calls to vmap() GEM objects
URL   : https://patchwork.freedesktop.org/series/3688/
State : failure

== Summary ==

Series 3688v1 Reorganise calls to vmap() GEM objects
http://patchwork.freedesktop.org/api/1.0/series/3688/revisions/1/mbox/

Test core_prop_blob:
Subgroup basic:
incomplete -> PASS   (snb-x220t)
Test drv_getparams_basic:
Subgroup basic-eu-total:
incomplete -> PASS   (snb-x220t)
Test gem_cs_prefetch:
Subgroup basic-default:
incomplete -> PASS   (ilk-hp8440p)
Test gem_ctx_param_basic:
Subgroup basic:
incomplete -> PASS   (snb-x220t)
Subgroup basic-default:
incomplete -> PASS   (snb-x220t)
Subgroup non-root-set:
incomplete -> PASS   (snb-x220t)
Subgroup root-set:
incomplete -> PASS   (snb-x220t)
Subgroup root-set-no-zeromap-disabled:
incomplete -> PASS   (snb-x220t)
Test gem_exec_basic:
Subgroup basic-bsd2:
incomplete -> SKIP   (snb-x220t)
Subgroup basic-default:
incomplete -> PASS   (snb-x220t)
Test gem_exec_parse:
Subgroup basic-rejected:
incomplete -> SKIP   (snb-x220t)
Test gem_flink_basic:
Subgroup bad-flink:
incomplete -> PASS   (snb-x220t)
Subgroup basic:
incomplete -> PASS   (snb-x220t)
Subgroup double-flink:
incomplete -> PASS   (snb-x220t)
Test gem_mmap:
Subgroup basic:
incomplete -> PASS   (snb-x220t)
Test gem_mmap_gtt:
Subgroup basic:
incomplete -> PASS   (snb-x220t)
Subgroup basic-read:
incomplete -> PASS   (snb-x220t)
Subgroup basic-read-write:
incomplete -> PASS   (snb-x220t)
Subgroup basic-small-copy-xy:
incomplete -> PASS   (snb-x220t)
Subgroup basic-write-gtt:
incomplete -> PASS   (snb-x220t)
Subgroup basic-write-read-distinct:
incomplete -> PASS   (snb-x220t)
Test gem_pread:
Subgroup basic:
incomplete -> PASS   (snb-x220t)
Test gem_pwrite:
Subgroup basic:
incomplete -> PASS   (snb-x220t)
Test gem_render_linear_blits:
Subgroup basic:
incomplete -> PASS   (snb-x220t)
Test gem_render_tiled_blits:
Subgroup basic:
incomplete -> PASS   (snb-x220t)
Test gem_ringfill:
Subgroup basic-default-child:
incomplete -> PASS   (snb-x220t)
Subgroup basic-default-interruptible:
incomplete -> PASS   (snb-x220t)
Test gem_storedw_loop:
Subgroup basic-vebox:
incomplete -> SKIP   (snb-x220t)
Test gem_sync:
Subgroup basic-bsd:
incomplete -> PASS   (snb-x220t)
Test kms_addfb_basic:
Subgroup addfb25-bad-modifier:
incomplete -> PASS   (snb-x220t)
Subgroup addfb25-modifier-no-flag:
incomplete -> PASS   (snb-x220t)
Subgroup addfb25-y-tiled-small:
incomplete -> SKIP   (snb-x220t)
Subgroup addfb25-yf-tiled:
incomplete -> PASS   (snb-x220t)
Subgroup bad-pitch-0:
incomplete -> PASS   (snb-x220t)
Subgroup basic:
incomplete -> PASS   (snb-x220t)
Subgroup bo-too-small-due-to-tiling:
incomplete -> PASS   (snb-x220t)
Subgroup no-handle:
incomplete -> PASS   (snb-x220t)
Subgroup size-max:
incomplete -> PASS   (snb-x220t)
Subgroup too-high:
incomplete -> PASS   (snb-x220t)
Subgroup unused-handle:
incomplete -> PASS   (snb-x220t)
Subgroup unused-modifier:
incomplete -> PASS   (snb-x220t)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass   -> DMESG-WARN (ilk-hp8440p) UNSTABLE
Subgroup basic-flip-vs-wf_vblank:
fail   -> PASS   (snb-x220t)
Test kms_force_connector_basic:
Subgroup force-load-detect:
dmesg-fail -> FAIL   (snb-x220t)
Test kms_pipe_crc_basic:
Subgroup bad-nb-words-1:
incomplete -> PASS   (snb-x220t)
Subgroup bad-source:
incomplete -> PASS   (snb-x220t)
Subgroup hang-read-crc-pipe-b:
incomplete -> PASS   (snb-x220t)
Subgroup hang-read-crc-pipe-c:
incomplete -> SKIP   (snb-x220t)
Subgroup nonblocking-crc-pipe-a-frame-sequence:
incomplete -> PASS   (snb-x220t)
Subgroup nonblocking-crc-pipe-b-frame-sequence:

Re: [Intel-gfx] [PATCH] drm/i915: Avoid divbyzero in modesetting

[Maarten Lankhorst]

Op 22-02-16 om 15:27 schreef Tvrtko Ursulin:
> [   10.062881]  [] skl_update_pipe_wm+0x102/0x8c0 [i915]
> [   10.062942]  [] skl_update_wm+0xff/0x5f0 [i915]
> [   10.063027]  [] intel_update_watermarks+0x1e/0x30 [i915]
> [   10.063087]  [] intel_crtc_disable_noatomic+0xd2/0x150 
> [i915]
> [   10.063148]  [] intel_modeset_setup_hw_state+0xdd2/0xde0 
> [i915]
> [   10.063181]  [] intel_modeset_init+0x15a3/0x1950 [i915]
> [   10.063181]  [] i915_driver_load+0x13c6/0x1720 [i915]
Do you have a full oops I can use for a commit description?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx