Re: [Intel-gfx] [PATCH] drm/i915: Fix missing unlock on error in i915_ppgtt_info()

[Daniel Vetter]

On Mon, Jun 13, 2016 at 11:42:00PM +, weiyj...@163.com wrote:
> From: Wei Yongjun 
> 
> Add the missing unlock before return from function i915_ppgtt_info()
> in the error handling case.
> 
> Fixes: 1d2ac403ae3b(drm: Protect dev->filelist with its own mutex)
> Signed-off-by: Wei Yongjun 

Applied to drm-misc, thanks.
-Daniel

> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 3269033..1035468 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2365,16 +2365,16 @@ static int i915_ppgtt_info(struct seq_file *m, void 
> *data)
>   task = get_pid_task(file->pid, PIDTYPE_PID);
>   if (!task) {
>   ret = -ESRCH;
> - goto out_put;
> + goto out_unlock;
>   }
>   seq_printf(m, "\nproc: %s\n", task->comm);
>   put_task_struct(task);
>   idr_for_each(_priv->context_idr, per_file_ctx,
>(void *)(unsigned long)m);
>   }
> +out_unlock:
>   mutex_unlock(>filelist_mutex);
>  
> -out_put:
>   intel_runtime_pm_put(dev_priv);
>   mutex_unlock(>struct_mutex);
> 
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915/skl: Increase cursor ddb blocks in multi-pipe config

[Patchwork]

== Series Details ==

Series: drm/i915/skl: Increase cursor ddb blocks in multi-pipe config
URL   : https://patchwork.freedesktop.org/series/8656/
State : failure

== Summary ==

Series 8656v1 drm/i915/skl: Increase cursor ddb blocks in multi-pipe config
http://patchwork.freedesktop.org/api/1.0/series/8656/revisions/1/mbox

Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-a-frame-sequence:
pass   -> FAIL   (ro-bdw-i7-5557U)

fi-bdw-i7-5557u  total:213  pass:201  dwarn:0   dfail:0   fail:0   skip:12 
fi-skl-i7-6700k  total:213  pass:188  dwarn:0   dfail:0   fail:0   skip:25 
fi-snb-i7-2600   total:213  pass:174  dwarn:0   dfail:0   fail:0   skip:39 
ro-bdw-i5-5250u  total:213  pass:197  dwarn:2   dfail:0   fail:0   skip:14 
ro-bdw-i7-5557U  total:213  pass:197  dwarn:0   dfail:0   fail:1   skip:15 
ro-bdw-i7-5600u  total:213  pass:185  dwarn:0   dfail:0   fail:0   skip:28 
ro-bsw-n3050 total:213  pass:172  dwarn:0   dfail:0   fail:2   skip:39 
ro-byt-n2820 total:213  pass:173  dwarn:0   dfail:0   fail:3   skip:37 
ro-hsw-i3-4010u  total:213  pass:190  dwarn:0   dfail:0   fail:0   skip:23 
ro-hsw-i7-4770r  total:213  pass:190  dwarn:0   dfail:0   fail:0   skip:23 
ro-ilk-i7-620lm  total:213  pass:150  dwarn:0   dfail:0   fail:1   skip:62 
ro-ilk1-i5-650   total:208  pass:150  dwarn:0   dfail:0   fail:1   skip:57 
ro-ivb-i7-3770   total:213  pass:181  dwarn:0   dfail:0   fail:0   skip:32 
ro-ivb2-i7-3770  total:213  pass:185  dwarn:0   dfail:0   fail:0   skip:28 
ro-skl3-i5-6260u total:213  pass:201  dwarn:1   dfail:0   fail:0   skip:11 
ro-snb-i7-2620M  total:213  pass:174  dwarn:0   dfail:0   fail:1   skip:38 
fi-hsw-i7-4770k failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1179/

b7936d4 drm-intel-nightly: 2016y-06m-13d-16h-41m-03s UTC integration manifest
e4d9faf drm/i915/skl: Increase cursor ddb blocks in multi-pipe config

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

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915/guc: updates to GuC doorbell handling (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/guc: updates to GuC doorbell handling (rev2)
URL   : https://patchwork.freedesktop.org/series/8553/
State : failure

== Summary ==

Series 8553v2 drm/i915/guc: updates to GuC doorbell handling
http://patchwork.freedesktop.org/api/1.0/series/8553/revisions/2/mbox

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-cmd:
fail   -> PASS   (ro-byt-n2820)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
pass   -> FAIL   (ro-bdw-i7-5600u)

fi-bdw-i7-5557u  total:213  pass:201  dwarn:0   dfail:0   fail:0   skip:12 
fi-skl-i7-6700k  total:213  pass:188  dwarn:0   dfail:0   fail:0   skip:25 
fi-snb-i7-2600   total:213  pass:174  dwarn:0   dfail:0   fail:0   skip:39 
ro-bdw-i7-5600u  total:213  pass:184  dwarn:0   dfail:0   fail:1   skip:28 
ro-bsw-n3050 total:213  pass:172  dwarn:0   dfail:0   fail:2   skip:39 
ro-byt-n2820 total:213  pass:174  dwarn:0   dfail:0   fail:2   skip:37 
ro-hsw-i3-4010u  total:213  pass:190  dwarn:0   dfail:0   fail:0   skip:23 
ro-hsw-i7-4770r  total:213  pass:190  dwarn:0   dfail:0   fail:0   skip:23 
ro-ilk-i7-620lm  total:213  pass:150  dwarn:0   dfail:0   fail:1   skip:62 
ro-ilk1-i5-650   total:208  pass:150  dwarn:0   dfail:0   fail:1   skip:57 
ro-ivb-i7-3770   total:213  pass:181  dwarn:0   dfail:0   fail:0   skip:32 
ro-ivb2-i7-3770  total:213  pass:185  dwarn:0   dfail:0   fail:0   skip:28 
ro-skl3-i5-6260u total:213  pass:201  dwarn:1   dfail:0   fail:0   skip:11 
ro-snb-i7-2620M  total:213  pass:174  dwarn:0   dfail:0   fail:1   skip:38 
fi-hsw-i7-4770k failed to connect after reboot
ro-bdw-i5-5250u failed to connect after reboot
ro-bdw-i7-5557U failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1178/

b7936d4 drm-intel-nightly: 2016y-06m-13d-16h-41m-03s UTC integration manifest
58358c2 drm/i915/guc: (re)initialise doorbell h/w when enabling GuC submission
6dcd14b drm/i915/guc: replace assign_doorbell() with select_doorbell_register()
0015c92 drm/i915/guc: refactor doorbell management code
1c6d522 drm/i915/guc: move guc_ring_doorbell() nearer to callsite
e42a6c9 drm/i915/guc: remove writes to GEN8_DRBREG registers
046480b drm/i915/guc: prefer __set/clear_bit() to bitmap_set/clear()
574f560 drm/i915/guc: add doorbell map to debugfs/i915_guc_info

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

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

[Stephen Rothwell]

Hi Dave,

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

  drivers/gpu/drm/i915/intel_display.c

between commit:

  a5aac5ab876a ("drm/i915: Check VBT for port presence in addition to the strap 
on VLV/CHV")

from the drm-intel-fixes tree and commit:

  457c52d87e5d ("drm/i915: Only ignore eDP ports that are connected")
(which is also in the drm-intel-fixes tree)

from the drm tree.

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

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

Re: [Intel-gfx] [PATCH 3/3] drm/i915/psr: Do not activate PSR when vblank interrupts are enabled

[Vivi, Rodrigo]

On Wed, 2016-06-08 at 18:46 -0700, Dhinakaran Pandiyan wrote:
> PSR in CHV, unlike HSW, can get activated even if vblanks interrupts
> are
> enabled. But, the pipe is not expected to generate timings signals
> when PSR is active. Specifically, we do not get vblank interrupts in
> CHV
> if PSR becomes active. This has led to drm_wait_vblank timing out.
> 
> Let's disable PSR using the vblank prepare hook that gets called
> before
> enabling vblank interrupts and keep it disabled until the interrupts
> are
> not needed.
> 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  1 +
>  drivers/gpu/drm/i915/i915_irq.c  | 12 
>  drivers/gpu/drm/i915/intel_drv.h |  2 ++
>  drivers/gpu/drm/i915/intel_psr.c | 61
> +++-
>  4 files changed, 75 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> index e4c8e34..03f311e 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -994,6 +994,7 @@ struct i915_psr {
>   bool psr2_support;
>   bool aux_frame_sync;
>   bool link_standby;
> + bool vlv_src_timing;
>  };
>  
>  enum intel_pch {
> diff --git a/drivers/gpu/drm/i915/i915_irq.c
> b/drivers/gpu/drm/i915/i915_irq.c
> index caaf1e2..77f3d76 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2790,6 +2790,16 @@ static int gen8_enable_vblank(struct
> drm_device *dev, unsigned int pipe)
>   return 0;
>  }
>  
> +static void valleyview_prepare_vblank(struct drm_device *dev,
> unsigned int pipe)
> +{

shouldn't we force psr_exit here? What if vblank is enabled after psr
is already in active mode?

> + vlv_psr_src_timing_get(dev);
> +}
> +
> +static void valleyview_unprepare_vblank(struct drm_device *dev,
> unsigned int pipe){
> +
> + vlv_psr_src_timing_put(dev);
> +}
> +
>  /* Called from drm generic code, passed 'crtc' which
>   * we use as a pipe index
>   */
> @@ -4610,6 +4620,8 @@ void intel_irq_init(struct drm_i915_private
> *dev_priv)
>   dev->driver->irq_uninstall =
> cherryview_irq_uninstall;
>   dev->driver->enable_vblank =
> valleyview_enable_vblank;
>   dev->driver->disable_vblank =
> valleyview_disable_vblank;
> + dev->driver->prepare_vblank =
> valleyview_prepare_vblank;
> + dev->driver->unprepare_vblank =
> valleyview_unprepare_vblank;
>   dev_priv->display.hpd_irq_setup =
> i915_hpd_irq_setup;
>   } else if (IS_VALLEYVIEW(dev_priv)) {
>   dev->driver->irq_handler = valleyview_irq_handler;
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 9b5f663..e2078fd 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1511,6 +1511,8 @@ void intel_psr_flush(struct drm_device *dev,
>  void intel_psr_init(struct drm_device *dev);
>  void intel_psr_single_frame_update(struct drm_device *dev,
>  unsigned frontbuffer_bits);
> +void vlv_psr_src_timing_get(struct drm_device *dev);
> +void vlv_psr_src_timing_put(struct drm_device *dev);
>  
>  /* intel_runtime_pm.c */
>  int intel_power_domains_init(struct drm_i915_private *);
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index 29a09bf..c95e680 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -462,6 +462,7 @@ void intel_psr_enable(struct intel_dp *intel_dp)
>  
>   /* Enable PSR on the panel */
>   vlv_psr_enable_sink(intel_dp);
> + dev_priv->psr.vlv_src_timing = false;
>  
>   /* On HSW+ enable_source also means go to PSR
> entry/active
>* state as soon as idle_frame achieved and here
> would be
> @@ -608,8 +609,10 @@ static void intel_psr_work(struct work_struct
> *work)
>* The delayed work can race with an invalidate hence we
> need to
>* recheck. Since psr_flush first clears this and then
> reschedules we
>* won't ever miss a flush when bailing out here.
> +  * Also, do not enable PSR if source is required to generate
> timing
> +  * signals like vblanks.
>*/
> - if (dev_priv->psr.busy_frontbuffer_bits)
> + if (dev_priv->psr.busy_frontbuffer_bits || dev_priv
> ->psr.vlv_src_timing)
>   goto unlock;

I wonder if in this vlv_src_timing case the work should re-schedule
itself... otherwise we have the risk of psr staying disabled forever
right?


>  
>   intel_psr_activate(intel_dp);
> @@ -708,6 +711,62 @@ void intel_psr_single_frame_update(struct
> drm_device *dev,
>  }
>  
>  /**
> + * vlv_psr_src_timing_get - src timing generation requested
> + *
> + * CHV does not have HW tracking to trigger PSR exit when VBI are
> enabled nor
> + * does enabling vblank interrupts prevent PSR entry. This function
> 

[Intel-gfx] [PATCH] drm/i915: Fix missing unlock on error in i915_ppgtt_info()

[weiyj_lk]

From: Wei Yongjun 

Add the missing unlock before return from function i915_ppgtt_info()
in the error handling case.

Fixes: 1d2ac403ae3b(drm: Protect dev->filelist with its own mutex)
Signed-off-by: Wei Yongjun 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 3269033..1035468 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2365,16 +2365,16 @@ static int i915_ppgtt_info(struct seq_file *m, void 
*data)
task = get_pid_task(file->pid, PIDTYPE_PID);
if (!task) {
ret = -ESRCH;
-   goto out_put;
+   goto out_unlock;
}
seq_printf(m, "\nproc: %s\n", task->comm);
put_task_struct(task);
idr_for_each(_priv->context_idr, per_file_ctx,
 (void *)(unsigned long)m);
}
+out_unlock:
mutex_unlock(>filelist_mutex);
 
-out_put:
intel_runtime_pm_put(dev_priv);
mutex_unlock(>struct_mutex);


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

[Intel-gfx] [PATCH] drm/i915/skl: Increase cursor ddb blocks in multi-pipe config

[Radhakrishna Sripada]

The bspec suggests giving cursor planes a fixed allocation of 8
blocks when running in a multi-CRTC configuration.  However we
have found that this small allocation can only accommodate level
0 watermarks on many platforms, which in turn prevents the
system from entering deeper sleep states.  Let's use a slightly
higher allocation of 16 blocks for the cursor to increase our
chances of enabling lower power states.

Signed-off-by: Radhakrishna Sripada 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/intel_pm.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 658a756..a949dac 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2933,7 +2933,8 @@ static unsigned int skl_cursor_allocation(int num_active)
if (num_active == 1)
return 32;
 
-   return 8;
+   /* higher than bspec recommendation (8) */
+   return 16;
 }
 
 static void skl_ddb_entry_init_from_hw(struct skl_ddb_entry *entry, u32 reg)
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915:bxt: Enable Pooled EU support

[Michał Winiarski]

On Fri, Jun 03, 2016 at 06:34:33AM +0100, Arun Siluvery wrote:
> This mode allows to assign EUs to pools which can process work collectively.
> The command to enable this mode should be issued as part of context 
> initialization.
> 
> The pooled mode is global, once enabled it has to stay the same across all
> contexts until HW reset hence this is sent in auxiliary golden context batch.
> Thanks to Mika for the preliminary review and comments.
> 
> v2: explain why this is enabled in golden context, use feature flag while
> enabling the support (Chris)
> 
> v3: Include only kernel support as userspace support is not available yet.
> 
> User space clients need to know when the pooled EU feature is present
> and enabled on the hardware so that they can adapt work submissions.
> Create a new device info flag for this purpose.
> 
> Set has_pooled_eu to true in the Broxton static device info - Broxton
> supports the feature in hardware and the driver will enable it by
> default.
> 
> We need to add getparam ioctls to enable userspace to query availability of
> this feature and to retrieve min. no of eus in a pool but we will expose
> them once userspace support is available. Opensource users for this feature
> are mesa, libva and beignet.
> 
> Beignet team is currently working on adding userspace support.
> 
> Reviewed-by: Chris Wilson  (v2)

Reviewed-by: Michał Winiarski 

-Michał

> Cc: Winiarski, Michal 
> Cc: Zou, Nanhai 
> Cc: Yang, Rong R 
> Cc: Mika Kuoppala 
> Cc: Chris Wilson 
> Cc: Armin Reese 
> Cc: Tim Gore 
> Signed-off-by: Jeff McGee 
> Signed-off-by: Arun Siluvery 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c  |  4 
>  drivers/gpu/drm/i915/i915_dma.c  | 19 +++
>  drivers/gpu/drm/i915/i915_drv.c  |  1 +
>  drivers/gpu/drm/i915/i915_drv.h  |  6 +-
>  drivers/gpu/drm/i915/i915_gem_render_state.c | 28 
> 
>  drivers/gpu/drm/i915/i915_reg.h  |  2 ++
>  6 files changed, 59 insertions(+), 1 deletion(-)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3 5/7] drm/i915/guc: refactor doorbell management code

[Dave Gordon]

This patch refactors the driver's handling and tracking of doorbells, in
preparation for a later one which will resolve a suspend-resume issue.

There are three resources to be managed:
1. Cachelines: a single line within the client-object's page 0
   is snooped by doorbell hardware for writes from the host.
2. Doorbell registers: each defines one cacheline to be snooped.
3. Bitmap: tracks which doorbell registers are in use.

The doorbell setup/teardown protocol starts with:
1. Pick a cacheline: select_doorbell_cacheline()
2. Find an available doorbell register: assign_doorbell()
(These values are passed to the GuC via the shared context
descriptor; this part of the sequence remains unchanged).

3. Update the bitmap to reflect registers-in-use
4. Prepare the cacheline for use by setting its status to ENABLED
5. Ask the GuC to program the doorbell to snoop the cacheline

and of course teardown is very similar:
6. Set the cacheline to DISABLED
7. Ask the GuC to reprogram the doorbell to stop snooping
8. Record that the doorbell is not in use.

Operations 6-8 (guc_disable_doorbell(), host2guc_release_doorbell(), and
release_doorbell()) were called in sequence from guc_client_free(), but
are now moved into the teardown phase of the common function.

Steps 4-5 (guc_init_doorbell() and host2guc_allocate_doorbell()) were
similarly done as sequential steps in guc_client_alloc(), but since it
turns out that we don't need to be able to do them separately they're
now collected into the setup phase of the common function.

The only new code (and new capability) is the block tagged
/* Update the GuC's idea of the doorbell ID */
i.e. we can now *change* the doorbell register used by an existing
client, whereas previously it was set once for the entire lifetime
of the client. We will use this new feature in the next patch.

v2: Trivial independent fixes pushed ahead as separate patches.
MUCH longer commit message :) [Tvrtko Ursulin]

Signed-off-by: Dave Gordon 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 94 +-
 1 file changed, 53 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 1c4ff3c..62bf4bd 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -174,31 +174,59 @@ static int host2guc_sample_forcewake(struct intel_guc 
*guc,
  * client object which contains the page being used for the doorbell
  */
 
-static void guc_init_doorbell(struct intel_guc *guc,
- struct i915_guc_client *client)
+static int guc_update_doorbell_id(struct intel_guc *guc,
+ struct i915_guc_client *client,
+ u16 new_id)
 {
+   struct sg_table *sg = guc->ctx_pool_obj->pages;
+   void *doorbell_bitmap = guc->doorbell_bitmap;
struct guc_doorbell_info *doorbell;
+   struct guc_context_desc desc;
+   size_t len;
 
doorbell = client->client_base + client->doorbell_offset;
 
-   doorbell->db_status = GUC_DOORBELL_ENABLED;
+   if (client->doorbell_id != GUC_INVALID_DOORBELL_ID &&
+   test_bit(client->doorbell_id, doorbell_bitmap)) {
+   /* Deactivate the old doorbell */
+   doorbell->db_status = GUC_DOORBELL_DISABLED;
+   (void)host2guc_release_doorbell(guc, client);
+   __clear_bit(client->doorbell_id, doorbell_bitmap);
+   }
+
+   /* Update the GuC's idea of the doorbell ID */
+   len = sg_pcopy_to_buffer(sg->sgl, sg->nents, , sizeof(desc),
+sizeof(desc) * client->ctx_index);
+   if (len != sizeof(desc))
+   return -EFAULT;
+   desc.db_id = new_id;
+   len = sg_pcopy_from_buffer(sg->sgl, sg->nents, , sizeof(desc),
+sizeof(desc) * client->ctx_index);
+   if (len != sizeof(desc))
+   return -EFAULT;
+
+   client->doorbell_id = new_id;
+   if (new_id == GUC_INVALID_DOORBELL_ID)
+   return 0;
+
+   /* Activate the new doorbell */
+   __set_bit(new_id, doorbell_bitmap);
doorbell->cookie = 0;
+   doorbell->db_status = GUC_DOORBELL_ENABLED;
+   return host2guc_allocate_doorbell(guc, client);
+}
+
+static int guc_init_doorbell(struct intel_guc *guc,
+ struct i915_guc_client *client,
+ uint16_t db_id)
+{
+   return guc_update_doorbell_id(guc, client, db_id);
 }
 
 static void guc_disable_doorbell(struct intel_guc *guc,
 struct i915_guc_client *client)
 {
-   struct drm_i915_private *dev_priv = guc_to_i915(guc);
-   struct guc_doorbell_info *doorbell;
-   i915_reg_t drbreg = GEN8_DRBREGL(client->doorbell_id);
-   int value;
-
-   doorbell = client->client_base + 

[Intel-gfx] [PATCH v3 3/7] drm/i915/guc: remove writes to GEN8_DRBREG registers

[Dave Gordon]

These registers are not actually writable by the CPU; only the GuC can
actually program them. So let's not do writes that have no effect.

Signed-off-by: Dave Gordon 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 21daaa5..1589fe9 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -252,14 +252,9 @@ static void guc_disable_doorbell(struct intel_guc *guc,
 
doorbell->db_status = GUC_DOORBELL_DISABLED;
 
-   I915_WRITE(drbreg, I915_READ(drbreg) & ~GEN8_DRB_VALID);
-
value = I915_READ(drbreg);
WARN_ON((value & GEN8_DRB_VALID) != 0);
 
-   I915_WRITE(GEN8_DRBREGU(client->doorbell_id), 0);
-   I915_WRITE(drbreg, 0);
-
/* XXX: wait for any interrupts */
/* XXX: wait for workqueue to drain */
 }
-- 
1.9.1

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

[Intel-gfx] [PATCH v3 7/7] drm/i915/guc: (re)initialise doorbell h/w when enabling GuC submission

[Dave Gordon]

During a hibernate/resume cycle, the whole system is reset, including
the GuC and the doorbell hardware. Then the system is booted up, drivers
are loaded, etc -- the GuC firmware may be loaded and set running at
this point. But then, the booted kernel is replaced by the hibernated
image, and this resumed kernel will also try to reload the GuC firmware
(which will fail). To recover, we reset the GuC and try again (which
should work). But this GuC reset doesn't also reset the doorbell
hardware, so it can be left in a state inconsistent with that assumed
by the driver and/or the newly-loaded GuC firmware.

It would be better if the GuC reset also cleared all doorbell state,
but that's not how the hardware currently works; also, the driver cannot
directly reprogram the doorbell hardware (only the GuC can do that).

So this patch cycles through all doorbells, assigning and releasing each
in turn, so that all the doorbell hardware is left in a consistent
state, no matter how it was programmed by the previously-running kernel
and/or GuC firmware.

v2: don't use kmap_atomic() now that client page 0 is kept mapped.

Signed-off-by: Dave Gordon 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 44 +-
 1 file changed, 43 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index a252505..22a55ac 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -693,6 +693,48 @@ static void gem_release_guc_obj(struct drm_i915_gem_object 
*obj)
kfree(client);
 }
 
+/*
+ * Borrow the first client to set up & tear down every doorbell
+ * in turn, to ensure that all doorbell h/w is (re)initialised.
+ */
+static void guc_init_doorbell_hw(struct intel_guc *guc)
+{
+   struct drm_i915_private *dev_priv = guc_to_i915(guc);
+   struct i915_guc_client *client = guc->execbuf_client;
+   uint16_t db_id, i;
+   int err;
+
+   db_id = client->doorbell_id;
+
+   for (i = 0; i < GUC_MAX_DOORBELLS; ++i) {
+   i915_reg_t drbreg = GEN8_DRBREGL(i);
+   u32 value = I915_READ(drbreg);
+
+   err = guc_update_doorbell_id(guc, client, i);
+
+   /* Report update failure or unexpectedly active doorbell */
+   if (err || (i != db_id && (value & GUC_DOORBELL_ENABLED)))
+   DRM_DEBUG_DRIVER("Doorbell %d (reg 0x%x) was 0x%x, err 
%d\n",
+ i, drbreg.reg, value, err);
+   }
+
+   /* Restore to original value */
+   err = guc_update_doorbell_id(guc, client, db_id);
+   if (err)
+   DRM_ERROR("Failed to restore doorbell to %d, err %d\n",
+   db_id, err);
+
+   for (i = 0; i < GUC_MAX_DOORBELLS; ++i) {
+   i915_reg_t drbreg = GEN8_DRBREGL(i);
+   u32 value = I915_READ(drbreg);
+
+   if (i != db_id && (value & GUC_DOORBELL_ENABLED))
+   DRM_DEBUG_DRIVER("Doorbell %d (reg 0x%x) finally 
0x%x\n",
+ i, drbreg.reg, value);
+
+   }
+}
+
 /**
  * guc_client_alloc() - Allocate an i915_guc_client
  * @dev_priv:  driver private data structure
@@ -956,8 +998,8 @@ int i915_guc_submission_enable(struct drm_i915_private 
*dev_priv)
}
 
guc->execbuf_client = client;
-
host2guc_sample_forcewake(guc, client);
+   guc_init_doorbell_hw(guc);
 
return 0;
 }
-- 
1.9.1

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

[Intel-gfx] [PATCH v3 6/7] drm/i915/guc: replace assign_doorbell() with select_doorbell_register()

[Dave Gordon]

This version doesn't update the doorbell bitmap, as that will
be done when the selected doorbell is associated with a client.

The call is now slightly earlier, just on the general principle
that potentially-failing operations should be done as early as
possible, to eliminate late failures and simplify recovery.

Suggested-by: Tvrtko Ursulin 
Signed-off-by: Dave Gordon 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 62 +++---
 1 file changed, 31 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 62bf4bd..a252505 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -232,6 +232,32 @@ static void guc_disable_doorbell(struct intel_guc *guc,
/* XXX: wait for workqueue to drain */
 }
 
+static uint16_t
+select_doorbell_register(struct intel_guc *guc, uint32_t priority)
+{
+   /*
+* The bitmap tracks which doorbell registers are currently in use.
+* It is split into two halves; the first half is used for normal
+* priority contexts, the second half for high-priority ones.
+* Note that logically higher priorities are numerically less than
+* normal ones, so the test below means "is it high-priority?"
+*/
+   const bool hi_pri = (priority <= GUC_CTX_PRIORITY_HIGH);
+   const uint16_t half = GUC_MAX_DOORBELLS / 2;
+   const uint16_t start = hi_pri ? half : 0;
+   const uint16_t end = start + half;
+   uint16_t id;
+
+   id = find_next_zero_bit(guc->doorbell_bitmap, end, start);
+   if (id == end)
+   id = GUC_INVALID_DOORBELL_ID;
+
+   DRM_DEBUG_DRIVER("assigned %s priority doorbell id 0x%x\n",
+   hi_pri ? "high" : "normal", id);
+
+   return id;
+}
+
 /*
  * Select, assign and relase doorbell cachelines
  *
@@ -256,32 +282,6 @@ static uint32_t select_doorbell_cacheline(struct intel_guc 
*guc)
return offset;
 }
 
-static uint16_t assign_doorbell(struct intel_guc *guc, uint32_t priority)
-{
-   /*
-* The bitmap is split into two halves; the first half is used for
-* normal priority contexts, the second half for high-priority ones.
-* Note that logically higher priorities are numerically less than
-* normal ones, so the test below means "is it high-priority?"
-*/
-   const bool hi_pri = (priority <= GUC_CTX_PRIORITY_HIGH);
-   const uint16_t half = GUC_MAX_DOORBELLS / 2;
-   const uint16_t start = hi_pri ? half : 0;
-   const uint16_t end = start + half;
-   uint16_t id;
-
-   id = find_next_zero_bit(guc->doorbell_bitmap, end, start);
-   if (id == end)
-   id = GUC_INVALID_DOORBELL_ID;
-   else
-   __set_bit(id, guc->doorbell_bitmap);
-
-   DRM_DEBUG_DRIVER("assigned %s priority doorbell id 0x%x\n",
-   hi_pri ? "high" : "normal", id);
-
-   return id;
-}
-
 /*
  * Initialise the process descriptor shared with the GuC firmware.
  */
@@ -742,6 +742,11 @@ static void gem_release_guc_obj(struct drm_i915_gem_object 
*obj)
client->wq_offset = GUC_DB_SIZE;
client->wq_size = GUC_WQ_SIZE;
 
+   db_id = select_doorbell_register(guc, client->priority);
+   if (db_id == GUC_INVALID_DOORBELL_ID)
+   /* XXX: evict a doorbell instead? */
+   goto err;
+
client->doorbell_offset = select_doorbell_cacheline(guc);
 
/*
@@ -754,11 +759,6 @@ static void gem_release_guc_obj(struct drm_i915_gem_object 
*obj)
else
client->proc_desc_offset = (GUC_DB_SIZE / 2);
 
-   db_id = assign_doorbell(guc, client->priority);
-   if (db_id == GUC_INVALID_DOORBELL_ID)
-   /* XXX: evict a doorbell instead */
-   goto err;
-
guc_init_proc_desc(guc, client);
guc_init_ctx_desc(guc, client);
if (guc_init_doorbell(guc, client, db_id))
-- 
1.9.1

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

[Intel-gfx] [PATCH v3 0/7] drm/i915/guc: updates to GuC doorbell handling

[Dave Gordon]

Various GuC (doorbell) related patches, some trivial. The bulk of the
changes are in [patch 5/7], but it's mostly just reorganisation of
existing code; and [patch 6/7] is just a followup to that, kept as a
separate change for reasons of clarity.  The new functionality is
implemented in a single new function in [patch 7/7].

Background, from v1 of this patchset:

The Linux hibernate/resume sequence involves booting one kernel, and
then replacing(!) its in-memory image with that of the previously
hibernated system.  This can lead to inconsistencies in the state of
the hardware, in particular where a driver does not or cannot reset
it to a well-defined initial state during resume.

For i915, the issue is that the doorbell hardware is not reset when
the GuC is reset; also, the driver *cannot* directly reprogram it:
only the GuC can do that. So this set of patches first reorganises
the doorbell handling, and then (in the last patch of the set)
ensures that the doorbell hardware is fully (re-)initialised when
the GuC is (re-)loaded.

v2:
  Patches reorganised (split), with longer commit message

v3:
  Rebased, patch [6/7] inserted into sequence

Dave Gordon (7):
  drm/i915/guc: add doorbell map to debugfs/i915_guc_info
  drm/i915/guc: prefer __set/clear_bit() to bitmap_set/clear()
  drm/i915/guc: remove writes to GEN8_DRBREG registers
  drm/i915/guc: move guc_ring_doorbell() nearer to callsite
  drm/i915/guc: refactor doorbell management code
  drm/i915/guc: replace assign_doorbell() with
select_doorbell_register()
  drm/i915/guc: (re)initialise doorbell h/w when enabling GuC submission

 drivers/gpu/drm/i915/i915_debugfs.c|   4 +
 drivers/gpu/drm/i915/i915_guc_submission.c | 301 +
 2 files changed, 179 insertions(+), 126 deletions(-)

-- 
1.9.1

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

[Intel-gfx] [PATCH v3 4/7] drm/i915/guc: move guc_ring_doorbell() nearer to callsite

[Dave Gordon]

Just code movement, no actual change to the function. This is in
preparation for the next patch, which will reorganise all the other
doorbell code, but doesn't change this function. So let's shuffle it
down near its caller rather than leaving it mixed in with the setup
code. Unlike the doorbell management code, this function is somewhat
time-critical, so putting it near its caller may even yield a tiny
performance improvement.

Signed-off-by: Dave Gordon 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 110 ++---
 1 file changed, 55 insertions(+), 55 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 1589fe9..1c4ff3c 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -185,61 +185,6 @@ static void guc_init_doorbell(struct intel_guc *guc,
doorbell->cookie = 0;
 }
 
-static int guc_ring_doorbell(struct i915_guc_client *gc)
-{
-   struct guc_process_desc *desc;
-   union guc_doorbell_qw db_cmp, db_exc, db_ret;
-   union guc_doorbell_qw *db;
-   int attempt = 2, ret = -EAGAIN;
-
-   desc = gc->client_base + gc->proc_desc_offset;
-
-   /* Update the tail so it is visible to GuC */
-   desc->tail = gc->wq_tail;
-
-   /* current cookie */
-   db_cmp.db_status = GUC_DOORBELL_ENABLED;
-   db_cmp.cookie = gc->cookie;
-
-   /* cookie to be updated */
-   db_exc.db_status = GUC_DOORBELL_ENABLED;
-   db_exc.cookie = gc->cookie + 1;
-   if (db_exc.cookie == 0)
-   db_exc.cookie = 1;
-
-   /* pointer of current doorbell cacheline */
-   db = gc->client_base + gc->doorbell_offset;
-
-   while (attempt--) {
-   /* lets ring the doorbell */
-   db_ret.value_qw = atomic64_cmpxchg((atomic64_t *)db,
-   db_cmp.value_qw, db_exc.value_qw);
-
-   /* if the exchange was successfully executed */
-   if (db_ret.value_qw == db_cmp.value_qw) {
-   /* db was successfully rung */
-   gc->cookie = db_exc.cookie;
-   ret = 0;
-   break;
-   }
-
-   /* XXX: doorbell was lost and need to acquire it again */
-   if (db_ret.db_status == GUC_DOORBELL_DISABLED)
-   break;
-
-   DRM_ERROR("Cookie mismatch. Expected %d, returned %d\n",
- db_cmp.cookie, db_ret.cookie);
-
-   /* update the cookie to newly read cookie from GuC */
-   db_cmp.cookie = db_ret.cookie;
-   db_exc.cookie = db_ret.cookie + 1;
-   if (db_exc.cookie == 0)
-   db_exc.cookie = 1;
-   }
-
-   return ret;
-}
-
 static void guc_disable_doorbell(struct intel_guc *guc,
 struct i915_guc_client *client)
 {
@@ -538,6 +483,61 @@ static void guc_add_workqueue_item(struct i915_guc_client 
*gc,
kunmap_atomic(base);
 }
 
+static int guc_ring_doorbell(struct i915_guc_client *gc)
+{
+   struct guc_process_desc *desc;
+   union guc_doorbell_qw db_cmp, db_exc, db_ret;
+   union guc_doorbell_qw *db;
+   int attempt = 2, ret = -EAGAIN;
+
+   desc = gc->client_base + gc->proc_desc_offset;
+
+   /* Update the tail so it is visible to GuC */
+   desc->tail = gc->wq_tail;
+
+   /* current cookie */
+   db_cmp.db_status = GUC_DOORBELL_ENABLED;
+   db_cmp.cookie = gc->cookie;
+
+   /* cookie to be updated */
+   db_exc.db_status = GUC_DOORBELL_ENABLED;
+   db_exc.cookie = gc->cookie + 1;
+   if (db_exc.cookie == 0)
+   db_exc.cookie = 1;
+
+   /* pointer of current doorbell cacheline */
+   db = gc->client_base + gc->doorbell_offset;
+
+   while (attempt--) {
+   /* lets ring the doorbell */
+   db_ret.value_qw = atomic64_cmpxchg((atomic64_t *)db,
+   db_cmp.value_qw, db_exc.value_qw);
+
+   /* if the exchange was successfully executed */
+   if (db_ret.value_qw == db_cmp.value_qw) {
+   /* db was successfully rung */
+   gc->cookie = db_exc.cookie;
+   ret = 0;
+   break;
+   }
+
+   /* XXX: doorbell was lost and need to acquire it again */
+   if (db_ret.db_status == GUC_DOORBELL_DISABLED)
+   break;
+
+   DRM_ERROR("Cookie mismatch. Expected %d, returned %d\n",
+ db_cmp.cookie, db_ret.cookie);
+
+   /* update the cookie to newly read cookie from GuC */
+   db_cmp.cookie = db_ret.cookie;
+   db_exc.cookie = db_ret.cookie + 1;
+   if (db_exc.cookie == 0)
+

[Intel-gfx] [PATCH v3 2/7] drm/i915/guc: prefer __set/clear_bit() to bitmap_set/clear()

[Dave Gordon]

Bitmap operators are overkill when touching only one bit.

Signed-off-by: Dave Gordon 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 65e67f0..21daaa5 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -306,7 +306,7 @@ static uint16_t assign_doorbell(struct intel_guc *guc, 
uint32_t priority)
if (id == end)
id = GUC_INVALID_DOORBELL_ID;
else
-   bitmap_set(guc->doorbell_bitmap, id, 1);
+   __set_bit(id, guc->doorbell_bitmap);
 
DRM_DEBUG_DRIVER("assigned %s priority doorbell id 0x%x\n",
hi_pri ? "high" : "normal", id);
@@ -316,7 +316,7 @@ static uint16_t assign_doorbell(struct intel_guc *guc, 
uint32_t priority)
 
 static void release_doorbell(struct intel_guc *guc, uint16_t id)
 {
-   bitmap_clear(guc->doorbell_bitmap, id, 1);
+   __clear_bit(id, guc->doorbell_bitmap);
 }
 
 /*
-- 
1.9.1

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

[Intel-gfx] [PATCH v3 1/7] drm/i915/guc: add doorbell map to debugfs/i915_guc_info

[Dave Gordon]

To properly verify the driver->doorbell->GuC functionality, validation
needs to know how the driver has assigned the doorbell cache lines and
registers, so make them visible through debugfs.

v2: use kernel bitmap-printing format (%pb) rather than %x.

Signed-off-by: Dave Gordon 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index e4f2c55..6efc8b1 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2574,6 +2574,10 @@ static int i915_guc_info(struct seq_file *m, void *data)
 
mutex_unlock(>struct_mutex);
 
+   seq_printf(m, "Doorbell map:\n");
+   seq_printf(m, "\t%*pb\n", GUC_MAX_DOORBELLS, guc.doorbell_bitmap);
+   seq_printf(m, "Doorbell next cacheline: 0x%x\n\n", guc.db_cacheline);
+
seq_printf(m, "GuC total action count: %llu\n", guc.action_count);
seq_printf(m, "GuC action failure count: %u\n", guc.action_fail);
seq_printf(m, "GuC last action command: 0x%x\n", guc.action_cmd);
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH 03/12] drm/i915: Add output_types bitmask into the crtc state

[Ville Syrjälä]

On Mon, Jun 13, 2016 at 04:25:55PM +0200, Daniel Vetter wrote:
> On Wed, Jun 08, 2016 at 01:41:38PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > Rather than looping through encoders to see which encoder types
> > are being driven by the pipe, add an output_types bitmask into
> > the crtc state and populate it prior to compute_config and during
> > state readout.
> > 
> > v2: Determine output_types before .compute_config() hooks are called
> > 
> > Signed-off-by: Ville Syrjälä 
> 
> Not sure whether this will mesh with LSPCON perfectly, but the atomic way
> is to pass connector_state and crtc_state to all encoder functions. That's
> at least how the atomic helpers in the core work, and it imo works well.
> i915 isn't there yet, but we want that anyway.
> 
> Once you have the connector_state, the connector is just a pointer away.
> And the functions which care can look up the connector type.
> 
> I'd like to go that direction since it would align i915 more with core
> atomic. And that misalignment is imo a big reason for why our transition
> is so super painful.

We want the bitmask anyway since we want to figure things out about
the output type in places where we have no connector state (eg. DPLL
code , or when when we'd have to deal with multiple connector states
(cloning).

> -Daniel
> 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 51 
> > +++-
> >  drivers/gpu/drm/i915/intel_drv.h |  5 
> >  2 files changed, 26 insertions(+), 30 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 12ff79594bc1..eabace447b1c 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -535,14 +535,7 @@ needs_modeset(struct drm_crtc_state *state)
> >   */
> >  bool intel_pipe_has_type(struct intel_crtc *crtc, enum intel_output_type 
> > type)
> >  {
> > -   struct drm_device *dev = crtc->base.dev;
> > -   struct intel_encoder *encoder;
> > -
> > -   for_each_encoder_on_crtc(dev, >base, encoder)
> > -   if (encoder->type == type)
> > -   return true;
> > -
> > -   return false;
> > +   return crtc->config->output_types & (1 << type);
> >  }
> >  
> >  /**
> > @@ -552,28 +545,9 @@ bool intel_pipe_has_type(struct intel_crtc *crtc, enum 
> > intel_output_type type)
> >   * encoder->crtc.
> >   */
> >  static bool intel_pipe_will_have_type(const struct intel_crtc_state 
> > *crtc_state,
> > - int type)
> > + enum intel_output_type type)
> >  {
> > -   struct drm_atomic_state *state = crtc_state->base.state;
> > -   struct drm_connector *connector;
> > -   struct drm_connector_state *connector_state;
> > -   struct intel_encoder *encoder;
> > -   int i, num_connectors = 0;
> > -
> > -   for_each_connector_in_state(state, connector, connector_state, i) {
> > -   if (connector_state->crtc != crtc_state->base.crtc)
> > -   continue;
> > -
> > -   num_connectors++;
> > -
> > -   encoder = to_intel_encoder(connector_state->best_encoder);
> > -   if (encoder->type == type)
> > -   return true;
> > -   }
> > -
> > -   WARN_ON(num_connectors == 0);
> > -
> > -   return false;
> > +   return crtc_state->output_types & (1 << type);
> >  }
> >  
> >  /*
> > @@ -12529,6 +12503,19 @@ intel_modeset_pipe_config(struct drm_crtc *crtc,
> >_config->pipe_src_w,
> >_config->pipe_src_h);
> >  
> > +   for_each_connector_in_state(state, connector, connector_state, i) {
> > +   if (connector_state->crtc != crtc)
> > +   continue;
> > +
> > +   encoder = to_intel_encoder(connector_state->best_encoder);
> > +
> > +   /*
> > +* Determine output_types before calling the .compute_config()
> > +* hooks so that the hooks can use this information safely.
> > +*/
> > +   pipe_config->output_types |= 1 << encoder->type;
> > +   }
> > +
> >  encoder_retry:
> > /* Ensure the port clock defaults are reset when retrying. */
> > pipe_config->port_clock = 0;
> > @@ -12826,6 +12813,7 @@ intel_pipe_config_compare(struct drm_device *dev,
> > PIPE_CONF_CHECK_M_N_ALT(dp_m_n, dp_m2_n2);
> >  
> > PIPE_CONF_CHECK_I(has_dsi_encoder);
> > +   PIPE_CONF_CHECK_X(output_types);
> >  
> > PIPE_CONF_CHECK_I(base.adjusted_mode.crtc_hdisplay);
> > PIPE_CONF_CHECK_I(base.adjusted_mode.crtc_htotal);
> > @@ -13093,8 +13081,10 @@ verify_crtc_state(struct drm_crtc *crtc,
> > "Encoder connected to wrong pipe %c\n",
> > pipe_name(pipe));
> >  
> > -   if (active)
> > +   if (active) {
> > +   pipe_config->output_types |= 1 << 

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [v2,RESEND,1/6] drm/i915/bxt: Wait for PHY1 GRC calibration synchronously

[Imre Deak]

On ma, 2016-06-13 at 14:23 +, Patchwork wrote:
> == Series Details ==
> 
> Series: series starting with [v2,RESEND,1/6] drm/i915/bxt: Wait for
> PHY1 GRC calibration synchronously
> URL   : https://patchwork.freedesktop.org/series/8627/
> State : failure
> 
> == Summary ==
> 
> Series 8627v1 Series without cover letter
> http://patchwork.freedesktop.org/api/1.0/series/8627/revisions/1/mbox
> 
> Test gem_exec_flush:
> Subgroup basic-batch-kernel-default-cmd:
> pass   -> FAIL   (ro-byt-n2820)

Pre-existing bug, unrelated platform:
https://bugs.freedesktop.org/show_bug.cgi?id=95372

Stack trace:
  #0 [__igt_fail_assert+0x101]
  #1 [gem_execbuf+0x44]
  #2 [batch+0x4c4]
  #3 [__real_main483+0x308]
  #4 [main+0x23]
  #5 [__libc_start_main+0xf0]
  #6 [_start+0x29]
  #7 [+0x29]
child 0 failed with exit status 99
Subtest basic-batch-kernel-default-cmd: FAIL (0.252s)

(gem_exec_flush:6032) ioctl-wrappers-CRITICAL: Test assertion failure
function gem_execbuf, file ioctl_wrappers.c:589:
(gem_exec_flush:6032) ioctl-wrappers-CRITICAL: Failed assertion:
__gem_execbuf(fd, execbuf) == 0
(gem_exec_flush:6032) ioctl-wrappers-CRITICAL: error: -22 != 0
Subtest basic-batch-kernel-default-cmd failed.


Thanks for the reviews, I pushed the patchset to -dinq.

--Imre

> fi-bdw-i7-
> 5557u  total:213  pass:201  dwarn:0   dfail:0   fail:0   skip:12 
> fi-skl-i7-
> 6700k  total:213  pass:188  dwarn:0   dfail:0   fail:0   skip:25 
> ro-bdw-i5-
> 5250u  total:213  pass:197  dwarn:2   dfail:0   fail:0   skip:14 
> ro-bdw-i7-
> 5557U  total:213  pass:198  dwarn:1   dfail:0   fail:0   skip:14 
> ro-bdw-i7-
> 5600u  total:213  pass:185  dwarn:0   dfail:0   fail:0   skip:28 
> ro-bsw-
> n3050 total:213  pass:171  dwarn:1   dfail:0   fail:2   skip:39 
> ro-byt-
> n2820 total:213  pass:173  dwarn:0   dfail:0   fail:3   skip:37 
> ro-hsw-i3-
> 4010u  total:213  pass:190  dwarn:0   dfail:0   fail:0   skip:23 
> ro-hsw-i7-
> 4770r  total:213  pass:190  dwarn:0   dfail:0   fail:0   skip:23 
> ro-ilk-i7-
> 620lm  total:213  pass:150  dwarn:0   dfail:0   fail:1   skip:62 
> ro-ilk1-i5-
> 650   total:208  pass:150  dwarn:0   dfail:0   fail:1   skip:57 
> ro-ivb-i7-
> 3770   total:213  pass:181  dwarn:0   dfail:0   fail:0   skip:32 
> ro-ivb2-i7-
> 3770  total:213  pass:185  dwarn:0   dfail:0   fail:0   skip:28 
> ro-skl3-i5-6260u
> total:213  pass:201  dwarn:1   dfail:0   fail:0   skip:11 
> ro-snb-i7-
> 2620M  total:213  pass:174  dwarn:0   dfail:0   fail:1   skip:38 
> fi-hsw-i7-4770k failed to connect after reboot
> fi-skl-i5-6260u failed to connect after reboot
> fi-snb-i7-2600 failed to connect after reboot
> 
> Results at /archive/results/CI_IGT_test/RO_Patchwork_1176/
> 
> 9dfa9b5 drm-intel-nightly: 2016y-06m-13d-13h-48m-21s UTC integration
> manifest
> 361caba drm/i915/bxt: Sanitiy check the PHY lane power down status
> ab4f3b4 drm/i915/bxt: Rename broxton to bxt in PHY/CDCLK function
> prefixes
> d130ab9 drm/i915/bxt: Set DDI PHY lane latency optimization during
> modeset
> aeba9cb drm/i915/bxt: Move DDI PHY enabling/disabling to the power
> well code
> 4d8024d drm/i915: Factor out intel_power_well_get/put
> db93190 drm/i915/bxt: Wait for PHY1 GRC calibration synchronously
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 7/6] drm/i915/guc: replace assign_doorbell() with select_doorbell_register()

[Dave Gordon]

This version doesn't update the doorbell bitmap, as that will
be done when the selected doorbell is associated with a client.

Also it's called a little earlier, just on the general principle
that potentially-failing operations should be done before those
that can't fail, to simplify error handling.

Suggested-by: Tvrtko Ursulin 
Signed-off-by: Dave Gordon 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 62 +++---
 1 file changed, 31 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 120d2e8..83c236c 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -232,6 +232,32 @@ static void guc_disable_doorbell(struct intel_guc *guc,
/* XXX: wait for workqueue to drain */
 }
 
+static uint16_t
+select_doorbell_register(struct intel_guc *guc, uint32_t priority)
+{
+   /*
+* The bitmap tracks which doorbell registers are currently in use.
+* It is split into two halves; the first half is used for normal
+* priority contexts, the second half for high-priority ones.
+* Note that logically higher priorities are numerically less than
+* normal ones, so the test below means "is it high-priority?"
+*/
+   const bool hi_pri = (priority <= GUC_CTX_PRIORITY_HIGH);
+   const uint16_t half = GUC_MAX_DOORBELLS / 2;
+   const uint16_t start = hi_pri ? half : 0;
+   const uint16_t end = start + half;
+   uint16_t id;
+
+   id = find_next_zero_bit(guc->doorbell_bitmap, end, start);
+   if (id == end)
+   id = GUC_INVALID_DOORBELL_ID;
+
+   DRM_DEBUG_DRIVER("assigned %s priority doorbell id 0x%x\n",
+   hi_pri ? "high" : "normal", id);
+
+   return id;
+}
+
 /*
  * Select, assign and relase doorbell cachelines
  *
@@ -256,32 +282,6 @@ static uint32_t select_doorbell_cacheline(struct intel_guc 
*guc)
return offset;
 }
 
-static uint16_t assign_doorbell(struct intel_guc *guc, uint32_t priority)
-{
-   /*
-* The bitmap is split into two halves; the first half is used for
-* normal priority contexts, the second half for high-priority ones.
-* Note that logically higher priorities are numerically less than
-* normal ones, so the test below means "is it high-priority?"
-*/
-   const bool hi_pri = (priority <= GUC_CTX_PRIORITY_HIGH);
-   const uint16_t half = GUC_MAX_DOORBELLS / 2;
-   const uint16_t start = hi_pri ? half : 0;
-   const uint16_t end = start + half;
-   uint16_t id;
-
-   id = find_next_zero_bit(guc->doorbell_bitmap, end, start);
-   if (id == end)
-   id = GUC_INVALID_DOORBELL_ID;
-   else
-   __set_bit(id, guc->doorbell_bitmap);
-
-   DRM_DEBUG_DRIVER("assigned %s priority doorbell id 0x%x\n",
-   hi_pri ? "high" : "normal", id);
-
-   return id;
-}
-
 /*
  * Initialise the process descriptor shared with the GuC firmware.
  */
@@ -785,6 +785,11 @@ static struct i915_guc_client *guc_client_alloc(struct 
drm_device *dev,
client->wq_offset = GUC_DB_SIZE;
client->wq_size = GUC_WQ_SIZE;
 
+   db_id = select_doorbell_register(guc, client->priority);
+   if (db_id == GUC_INVALID_DOORBELL_ID)
+   /* XXX: evict a doorbell instead? */
+   goto err;
+
client->doorbell_offset = select_doorbell_cacheline(guc);
 
/*
@@ -797,11 +802,6 @@ static struct i915_guc_client *guc_client_alloc(struct 
drm_device *dev,
else
client->proc_desc_offset = (GUC_DB_SIZE / 2);
 
-   db_id = assign_doorbell(guc, client->priority);
-   if (db_id == GUC_INVALID_DOORBELL_ID)
-   /* XXX: evict a doorbell instead */
-   goto err;
-
guc_init_proc_desc(guc, client);
guc_init_ctx_desc(guc, client);
if (guc_init_doorbell(guc, client, db_id))
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH v2 5/6] drm/i915/guc: refactor doorbell management code

[Tvrtko Ursulin]

On 13/06/16 16:59, Dave Gordon wrote:

On 13/06/16 11:53, Tvrtko Ursulin wrote:


On 13/06/16 11:25, Dave Gordon wrote:

On 13/06/16 10:48, Tvrtko Ursulin wrote:


On 10/06/16 17:51, Dave Gordon wrote:

This patch refactors the driver's handling and tracking of
doorbells, in
preparation for a later one which will resolve a suspend-resume issue.

There are three resources to be managed:
1. Cachelines: a single line within the client-object's page 0
is snooped by doorbell hardware for writes from the host.
2. Doorbell registers: each defines one cacheline to be snooped.
3. Bitmap: tracks which doorbell registers are in use.

The doorbell setup/teardown protocol starts with:
1. Pick a cacheline: select_doorbell_cacheline()
2. Find an available doorbell register: assign_doorbell()
(These values are passed to the GuC via the shared context
descriptor; this part of the sequence remains unchanged).

3. Update the bitmap to reflect registers-in-use
4. Prepare the cacheline for use by setting its status to ENABLED
5. Ask the GuC to program the doorbell to snoop the cacheline

and of course teardown is very similar:
6. Set the cacheline to DISABLED
7. Ask the GuC to reprogram the doorbell to stop snooping
8. Record that the doorbell is not in use.

Operations 6-8 (guc_disable_doorbell(), host2guc_release_doorbell(),
and
release_doorbell()) were called in sequence from guc_client_free(),
but
are now moved into the teardown phase of the common function.

Steps 4-5 (guc_init_doorbell() and host2guc_allocate_doorbell()) were
similarly done as sequential steps in guc_client_alloc(), but since it
turns out that we don't need to be able to do them separately they're
now collected into the setup phase of the common function.

The only new code (and new capability) is the block tagged
 /* Update the GuC's idea of the doorbell ID */
i.e. we can now *change* the doorbell register used by an existing
client, whereas previously it was set once for the entire lifetime
of the client. We will use this new feature in the next patch.

v2: Trivial independent fixes pushed ahead as separate patches.
 MUCH longer commit message :) [Tvrtko Ursulin]

Signed-off-by: Dave Gordon 
---
  drivers/gpu/drm/i915/i915_guc_submission.c | 94
+-
  1 file changed, 53 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 45b33f8..1833bfd 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -174,31 +174,59 @@ static int host2guc_sample_forcewake(struct
intel_guc *guc,
   * client object which contains the page being used for the doorbell
   */

-static void guc_init_doorbell(struct intel_guc *guc,
-  struct i915_guc_client *client)
+static int guc_update_doorbell_id(struct intel_guc *guc,
+  struct i915_guc_client *client,
+  u16 new_id)
  {
+struct sg_table *sg = guc->ctx_pool_obj->pages;
+void *doorbell_bitmap = guc->doorbell_bitmap;
  struct guc_doorbell_info *doorbell;
+struct guc_context_desc desc;
+size_t len;

  doorbell = client->client_base + client->doorbell_offset;

-doorbell->db_status = GUC_DOORBELL_ENABLED;
+if (client->doorbell_id != GUC_INVALID_DOORBELL_ID &&
+test_bit(client->doorbell_id, doorbell_bitmap)) {
+/* Deactivate the old doorbell */
+doorbell->db_status = GUC_DOORBELL_DISABLED;
+(void)host2guc_release_doorbell(guc, client);
+__clear_bit(client->doorbell_id, doorbell_bitmap);
+}
+
+/* Update the GuC's idea of the doorbell ID */
+len = sg_pcopy_to_buffer(sg->sgl, sg->nents, , sizeof(desc),
+ sizeof(desc) * client->ctx_index);
+if (len != sizeof(desc))
+return -EFAULT;
+desc.db_id = new_id;
+len = sg_pcopy_from_buffer(sg->sgl, sg->nents, ,
sizeof(desc),
+ sizeof(desc) * client->ctx_index);
+if (len != sizeof(desc))
+return -EFAULT;
+
+client->doorbell_id = new_id;
+if (new_id == GUC_INVALID_DOORBELL_ID)
+return 0;
+
+/* Activate the new doorbell */
+__set_bit(new_id, doorbell_bitmap);


Is this the same bit as in assign_doorbell so redundant?


It is the same bit, and yes, it will be redundant during the initial
setup, but when we come to *re*assign the association between a client
and a doorbell (in the next patch) then it won't be.

We could also choose to have assign_doorbell() NOT update the map, so
then this would be the only place where the bitmap gets updated. I'd
have to rename it though, as it would no longer be assigning anything!


Maybe pick_doorbell or find_free_doorbell? It would be a little bit
clearer and safer (early returns above could leave the bitmap set) with
a single bitmap update location so I think it would be worth it.

Regards,
Tvrtko


Roger wilco, but it looks simpler if I make it 

Re: [Intel-gfx] [PATCH v2 5/6] drm/i915/guc: refactor doorbell management code

[Dave Gordon]

On 13/06/16 11:53, Tvrtko Ursulin wrote:


On 13/06/16 11:25, Dave Gordon wrote:

On 13/06/16 10:48, Tvrtko Ursulin wrote:


On 10/06/16 17:51, Dave Gordon wrote:

This patch refactors the driver's handling and tracking of
doorbells, in
preparation for a later one which will resolve a suspend-resume issue.

There are three resources to be managed:
1. Cachelines: a single line within the client-object's page 0
is snooped by doorbell hardware for writes from the host.
2. Doorbell registers: each defines one cacheline to be snooped.
3. Bitmap: tracks which doorbell registers are in use.

The doorbell setup/teardown protocol starts with:
1. Pick a cacheline: select_doorbell_cacheline()
2. Find an available doorbell register: assign_doorbell()
(These values are passed to the GuC via the shared context
descriptor; this part of the sequence remains unchanged).

3. Update the bitmap to reflect registers-in-use
4. Prepare the cacheline for use by setting its status to ENABLED
5. Ask the GuC to program the doorbell to snoop the cacheline

and of course teardown is very similar:
6. Set the cacheline to DISABLED
7. Ask the GuC to reprogram the doorbell to stop snooping
8. Record that the doorbell is not in use.

Operations 6-8 (guc_disable_doorbell(), host2guc_release_doorbell(),
and
release_doorbell()) were called in sequence from guc_client_free(), but
are now moved into the teardown phase of the common function.

Steps 4-5 (guc_init_doorbell() and host2guc_allocate_doorbell()) were
similarly done as sequential steps in guc_client_alloc(), but since it
turns out that we don't need to be able to do them separately they're
now collected into the setup phase of the common function.

The only new code (and new capability) is the block tagged
 /* Update the GuC's idea of the doorbell ID */
i.e. we can now *change* the doorbell register used by an existing
client, whereas previously it was set once for the entire lifetime
of the client. We will use this new feature in the next patch.

v2: Trivial independent fixes pushed ahead as separate patches.
 MUCH longer commit message :) [Tvrtko Ursulin]

Signed-off-by: Dave Gordon 
---
  drivers/gpu/drm/i915/i915_guc_submission.c | 94
+-
  1 file changed, 53 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 45b33f8..1833bfd 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -174,31 +174,59 @@ static int host2guc_sample_forcewake(struct
intel_guc *guc,
   * client object which contains the page being used for the doorbell
   */

-static void guc_init_doorbell(struct intel_guc *guc,
-  struct i915_guc_client *client)
+static int guc_update_doorbell_id(struct intel_guc *guc,
+  struct i915_guc_client *client,
+  u16 new_id)
  {
+struct sg_table *sg = guc->ctx_pool_obj->pages;
+void *doorbell_bitmap = guc->doorbell_bitmap;
  struct guc_doorbell_info *doorbell;
+struct guc_context_desc desc;
+size_t len;

  doorbell = client->client_base + client->doorbell_offset;

-doorbell->db_status = GUC_DOORBELL_ENABLED;
+if (client->doorbell_id != GUC_INVALID_DOORBELL_ID &&
+test_bit(client->doorbell_id, doorbell_bitmap)) {
+/* Deactivate the old doorbell */
+doorbell->db_status = GUC_DOORBELL_DISABLED;
+(void)host2guc_release_doorbell(guc, client);
+__clear_bit(client->doorbell_id, doorbell_bitmap);
+}
+
+/* Update the GuC's idea of the doorbell ID */
+len = sg_pcopy_to_buffer(sg->sgl, sg->nents, , sizeof(desc),
+ sizeof(desc) * client->ctx_index);
+if (len != sizeof(desc))
+return -EFAULT;
+desc.db_id = new_id;
+len = sg_pcopy_from_buffer(sg->sgl, sg->nents, ,
sizeof(desc),
+ sizeof(desc) * client->ctx_index);
+if (len != sizeof(desc))
+return -EFAULT;
+
+client->doorbell_id = new_id;
+if (new_id == GUC_INVALID_DOORBELL_ID)
+return 0;
+
+/* Activate the new doorbell */
+__set_bit(new_id, doorbell_bitmap);


Is this the same bit as in assign_doorbell so redundant?


It is the same bit, and yes, it will be redundant during the initial
setup, but when we come to *re*assign the association between a client
and a doorbell (in the next patch) then it won't be.

We could also choose to have assign_doorbell() NOT update the map, so
then this would be the only place where the bitmap gets updated. I'd
have to rename it though, as it would no longer be assigning anything!


Maybe pick_doorbell or find_free_doorbell? It would be a little bit
clearer and safer (early returns above could leave the bitmap set) with
a single bitmap update location so I think it would be worth it.

Regards,
Tvrtko


Roger wilco, but it looks simpler if I make it a followup [7/6]?
Otherwise (if I mix it 

Re: [Intel-gfx] ✗ Ro.CI.BAT: warning for series starting with [1/2] drm/i915/guc: prefer 'dev_priv' to 'dev' for static functions

[Tvrtko Ursulin]

On 13/06/16 16:42, Dave Gordon wrote:

On 11/06/16 06:50, Patchwork wrote:

== Series Details ==

Series: series starting with [1/2] drm/i915/guc: prefer 'dev_priv' to
'dev' for static functions
URL   : https://patchwork.freedesktop.org/series/8556/
State : warning

== Summary ==

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

Test gem_exec_flush:
 Subgroup basic-batch-kernel-default-cmd:
 fail   -> PASS   (ro-byt-n2820)
Test kms_pipe_crc_basic:
 Subgroup hang-read-crc-pipe-a:
 dmesg-warn -> PASS   (ro-hsw-i3-4010u)
 Subgroup nonblocking-crc-pipe-b-frame-sequence:
 skip   -> PASS   (fi-skl-i5-6260u)
 Subgroup suspend-read-crc-pipe-a:
 skip   -> DMESG-WARN (ro-bdw-i5-5250u)
 Subgroup suspend-read-crc-pipe-b:
 skip   -> DMESG-WARN (ro-bdw-i5-5250u)


These are both an existing issue, logged as
https://bugs.freedesktop.org/show_bug.cgi?id=96448


 Subgroup suspend-read-crc-pipe-c:
 skip   -> PASS   (fi-skl-i5-6260u)

fi-bdw-i7-5557u  total:213  pass:201  dwarn:0   dfail:0   fail:0
skip:12
fi-skl-i5-6260u  total:213  pass:202  dwarn:0   dfail:0   fail:0
skip:11
fi-skl-i7-6700k  total:213  pass:188  dwarn:0   dfail:0   fail:0
skip:25
fi-snb-i7-2600   total:213  pass:174  dwarn:0   dfail:0   fail:0
skip:39
ro-bdw-i5-5250u  total:213  pass:197  dwarn:4   dfail:0   fail:0
skip:12
ro-bdw-i7-5600u  total:213  pass:185  dwarn:0   dfail:0   fail:0
skip:28
ro-bsw-n3050 total:213  pass:172  dwarn:0   dfail:0   fail:2
skip:39
ro-byt-n2820 total:213  pass:174  dwarn:0   dfail:0   fail:2
skip:37
ro-hsw-i3-4010u  total:213  pass:190  dwarn:0   dfail:0   fail:0
skip:23
ro-hsw-i7-4770r  total:213  pass:190  dwarn:0   dfail:0   fail:0
skip:23
ro-ilk-i7-620lm  total:177  pass:120  dwarn:2   dfail:2   fail:1
skip:51
ro-ilk1-i5-650   total:208  pass:150  dwarn:0   dfail:0   fail:1
skip:57
ro-ivb-i7-3770   total:213  pass:181  dwarn:0   dfail:0   fail:0
skip:32
ro-ivb2-i7-3770  total:213  pass:185  dwarn:0   dfail:0   fail:0
skip:28
ro-skl3-i5-6260u total:213  pass:201  dwarn:1   dfail:0   fail:0
skip:11
ro-snb-i7-2620M  total:213  pass:174  dwarn:0   dfail:0   fail:1
skip:38
fi-hsw-i7-4770k failed to connect after reboot
ro-bdw-i7-5557U failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1162/

94fd582 drm-intel-nightly: 2016y-06m-10d-16h-42m-36s UTC integration
manifest
4c20b95 drm/i915/guc: prefer 'dev_priv' to 'dev' for intra-module
functions
b0b12a6 drm/i915/guc: prefer 'dev_priv' to 'dev' for static functions


Merged, thanks for the patches and review! :)

Regards,

Tvrtko


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

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

[John Harrison]

On 07/06/2016 13:02, Maarten Lankhorst wrote:

Op 02-06-16 om 15:25 schreef Tvrtko Ursulin:

On 01/06/16 18:07, john.c.harri...@intel.com wrote:

From: John Harrison 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

For: VIZ-5190
Signed-off-by: John Harrison 
Cc: Tvrtko Ursulin 
Cc: Maarten Lankhorst 
---
   drivers/gpu/drm/i915/i915_dma.c |   9 +-
   drivers/gpu/drm/i915/i915_drv.h |  11 ++
   drivers/gpu/drm/i915/i915_gem.c | 248 
+---
   drivers/gpu/drm/i915/i915_irq.c |   2 +
   drivers/gpu/drm/i915/intel_lrc.c|   5 +
   drivers/gpu/drm/i915/intel_ringbuffer.c |   5 +
   drivers/gpu/drm/i915/intel_ringbuffer.h |   3 +
   7 files changed, 260 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 07edaed..f8f60bb 100644
--- a/drivers/gpu/drm/i915/i915_dma.c

Re: [Intel-gfx] ✗ Ro.CI.BAT: warning for series starting with [1/2] drm/i915/guc: prefer 'dev_priv' to 'dev' for static functions

[Dave Gordon]

On 11/06/16 06:50, Patchwork wrote:

== Series Details ==

Series: series starting with [1/2] drm/i915/guc: prefer 'dev_priv' to 'dev' for 
static functions
URL   : https://patchwork.freedesktop.org/series/8556/
State : warning

== Summary ==

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

Test gem_exec_flush:
 Subgroup basic-batch-kernel-default-cmd:
 fail   -> PASS   (ro-byt-n2820)
Test kms_pipe_crc_basic:
 Subgroup hang-read-crc-pipe-a:
 dmesg-warn -> PASS   (ro-hsw-i3-4010u)
 Subgroup nonblocking-crc-pipe-b-frame-sequence:
 skip   -> PASS   (fi-skl-i5-6260u)
 Subgroup suspend-read-crc-pipe-a:
 skip   -> DMESG-WARN (ro-bdw-i5-5250u)
 Subgroup suspend-read-crc-pipe-b:
 skip   -> DMESG-WARN (ro-bdw-i5-5250u)


These are both an existing issue, logged as
https://bugs.freedesktop.org/show_bug.cgi?id=96448


 Subgroup suspend-read-crc-pipe-c:
 skip   -> PASS   (fi-skl-i5-6260u)

fi-bdw-i7-5557u  total:213  pass:201  dwarn:0   dfail:0   fail:0   skip:12
fi-skl-i5-6260u  total:213  pass:202  dwarn:0   dfail:0   fail:0   skip:11
fi-skl-i7-6700k  total:213  pass:188  dwarn:0   dfail:0   fail:0   skip:25
fi-snb-i7-2600   total:213  pass:174  dwarn:0   dfail:0   fail:0   skip:39
ro-bdw-i5-5250u  total:213  pass:197  dwarn:4   dfail:0   fail:0   skip:12
ro-bdw-i7-5600u  total:213  pass:185  dwarn:0   dfail:0   fail:0   skip:28
ro-bsw-n3050 total:213  pass:172  dwarn:0   dfail:0   fail:2   skip:39
ro-byt-n2820 total:213  pass:174  dwarn:0   dfail:0   fail:2   skip:37
ro-hsw-i3-4010u  total:213  pass:190  dwarn:0   dfail:0   fail:0   skip:23
ro-hsw-i7-4770r  total:213  pass:190  dwarn:0   dfail:0   fail:0   skip:23
ro-ilk-i7-620lm  total:177  pass:120  dwarn:2   dfail:2   fail:1   skip:51
ro-ilk1-i5-650   total:208  pass:150  dwarn:0   dfail:0   fail:1   skip:57
ro-ivb-i7-3770   total:213  pass:181  dwarn:0   dfail:0   fail:0   skip:32
ro-ivb2-i7-3770  total:213  pass:185  dwarn:0   dfail:0   fail:0   skip:28
ro-skl3-i5-6260u total:213  pass:201  dwarn:1   dfail:0   fail:0   skip:11
ro-snb-i7-2620M  total:213  pass:174  dwarn:0   dfail:0   fail:1   skip:38
fi-hsw-i7-4770k failed to connect after reboot
ro-bdw-i7-5557U failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1162/

94fd582 drm-intel-nightly: 2016y-06m-10d-16h-42m-36s UTC integration manifest
4c20b95 drm/i915/guc: prefer 'dev_priv' to 'dev' for intra-module functions
b0b12a6 drm/i915/guc: prefer 'dev_priv' to 'dev' for static functions



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

Re: [Intel-gfx] [PATCH] drm/i915: prefer INTEL_GEN(dev_priv) to INTEL_INFO(dev)->gen

[Dave Gordon]

On 13/06/16 10:28, Tvrtko Ursulin wrote:


On 10/06/16 18:35, Dave Gordon wrote:

More Coccinellery ...

Wherever we find "INTEL_INFO(dev)->gen", and have a suitable
"dev_priv" in scope, replace it with "INTEL_GEN(dev_priv)".
At this time, we've found 189 instances, and each replacement
saves one memory cycle at runtime and two bytes of codespace
(~360 bytes total text size reduction).

@dev_priv_param@
function FUNC;
idexpression struct drm_device *DEV;
identifier DEV_PRIV;
@@
FUNC(..., struct drm_i915_private *DEV_PRIV, ...)
{
 <...
-   INTEL_INFO(DEV)->gen
+   INTEL_GEN(DEV_PRIV)
 ...>
}

@dev_priv_local@
idexpression struct drm_device *DEV;
identifier DEV_PRIV;
expression E;
@@
{
 ...
(
 struct drm_i915_private *DEV_PRIV;
|
 struct drm_i915_private *DEV_PRIV = E;
)
 <...
-   INTEL_INFO(DEV)->gen
+   INTEL_GEN(DEV_PRIV)
 ...>
}

Plus manual deletion of one now-unused local "dev".

Signed-off-by: Dave Gordon 
---
  drivers/gpu/drm/i915/i915_debugfs.c|  52 +++---
  drivers/gpu/drm/i915/i915_dma.c|  16 ++---
  drivers/gpu/drm/i915/i915_drv.c|   2 +-
  drivers/gpu/drm/i915/i915_gem.c|   4 +-
  drivers/gpu/drm/i915/i915_gem_execbuffer.c |   8 +--
  drivers/gpu/drm/i915/i915_gem_fence.c  |   8 +--
  drivers/gpu/drm/i915/i915_gem_gtt.c|  12 ++--
  drivers/gpu/drm/i915/i915_gem_stolen.c |   6 +-
  drivers/gpu/drm/i915/i915_gpu_error.c  |  14 ++--
  drivers/gpu/drm/i915/i915_irq.c|  12 ++--
  drivers/gpu/drm/i915/i915_suspend.c|  20 +++---
  drivers/gpu/drm/i915/intel_color.c |   2 +-
  drivers/gpu/drm/i915/intel_crt.c   |   6 +-
  drivers/gpu/drm/i915/intel_ddi.c   |   4 +-
  drivers/gpu/drm/i915/intel_display.c   | 111 ++---
  drivers/gpu/drm/i915/intel_dp.c|  20 +++---
  drivers/gpu/drm/i915/intel_dpll_mgr.c  |   2 +-
  drivers/gpu/drm/i915/intel_lvds.c  |   4 +-
  drivers/gpu/drm/i915/intel_pm.c|  18 ++---
  drivers/gpu/drm/i915/intel_psr.c   |   4 +-
  drivers/gpu/drm/i915/intel_sdvo.c  |   8 +--
  drivers/gpu/drm/i915/intel_tv.c|   2 +-
  22 files changed, 167 insertions(+), 168 deletions(-)


[snip]


@@ -553,7 +553,7 @@ void i915_gem_restore_fences(struct drm_device *dev)
  uint32_t swizzle_x = I915_BIT_6_SWIZZLE_UNKNOWN;
  uint32_t swizzle_y = I915_BIT_6_SWIZZLE_UNKNOWN;

-if (INTEL_INFO(dev)->gen >= 8 || IS_VALLEYVIEW(dev)) {
+if (INTEL_GEN(dev_priv) >= 8 || IS_VALLEYVIEW(dev)) {


While we are churning :), could looks for both dev_priv and dev in the
same condition like here and tidy those.


[snip]


A few instances of the small comment I made above, which I think would
be a good opportunity. Otherwise all looks OK.

Reviewed-by: Tvrtko Ursulin 

But needs more acks, since last time we discussed this conclusion was it
was too much disruption for the benefit.

Regards,
Tvrtko


Yes, that's why this was a minimal set for replacement of one specific 
but very common idiom that has a definite benefit. At the other extreme, 
I have a Cocci patch to replace *all* INTEL_INFO()->gen with INTEL_GEN() 
and then replace the 'dev' parameter to INTEL_INFO(), INTEL_GEN() and 
all the IS_X() macros wherever possible; but that really is a lot of 
churn for proportionately less benefit. Or we could pick replacements on 
a file-by-file basis rather than according to which macro they use. Or 
maybe one patch each for the big targets (debugfs.c, display.c) and 
another one that does all the files where there are only a few lines of 
changes.


Opinions, anybody?

.Dave.
___
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: Move fb_bits updating later in atomic_commit

[Chris Wilson]

On Mon, Jun 13, 2016 at 04:13:48PM +0200, Daniel Vetter wrote:
> Currently it's part of prepare_fb, still in the first phase of
> atomic_commit which might fail. Which means that we need to have some
> heuristics in cleanup_fb to figure out whether things failed, or
> whether we just clean up the old fbs.
> 
> That's fragile, and worse, once we start pipelining commits gets
> confused: While the last commit is still getting cleanup up we already
> hammer in the new one, and fb_bits aren't refcounted, resulting in
> lost bits and WARN_ON galore. We could instead try to make cleanup_fb
> more clever, but a simpler fix is to postpone the fb_bits tracking
> past the point of no return, where we commit all the software state.
> 
> That also makes conceptually more sense, since fb_bits must be updated
> synchronously from the ioctl (they track usage from userspace pov, not
> from the hw pov), right before we're fully committed to the updated.
> 
> This fixes WARNING splats from track_fb with page_flip implemented
> through atomic_commit.
> 
> Testcase: igt/kms_flip/flip-vs-rmfb
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 41 
> ++--
>  1 file changed, 25 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index a16a307dbb76..fd46db4882e5 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13863,6 +13863,25 @@ static void intel_atomic_commit_work(struct 
> work_struct *work)
>   intel_atomic_commit_tail(state);
>  }
>  
> +static void intel_atomic_track_fbs(struct drm_atomic_state *state)
> +{
> + struct drm_plane_state *old_plane_state;
> + struct drm_plane *plane;
> + struct drm_i915_gem_object *obj, *old_obj;
> + struct intel_plane *intel_plane;
> + int i;
> +
> + mutex_lock(>dev->struct_mutex);
> + for_each_plane_in_state(state, plane, old_plane_state, i) {
> + obj = intel_fb_obj(plane->state->fb);
> + old_obj = intel_fb_obj(old_plane_state->fb);
> + intel_plane = to_intel_plane(plane);
> +
> + i915_gem_track_fb(old_obj, obj, intel_plane->frontbuffer_bit);
> + }
> + mutex_unlock(>dev->struct_mutex);
> +}

Seems like an opportune time to pull in

https://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=tasklet=d16c3d8f3dd395b8d13a3691efb356a23e0b702b
https://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=tasklet=4a5c85282ba3c15a64dc0f600969234f30ebe820

and fwiw i915_gem_track_fb would be better off inside intel_display.c
-Chris

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

[Intel-gfx] [PATCH i-g-t] demos/intel_sprite_on: Fix connector iteration bug

[Jim Bride]

Instead of looping until the first disconnected port is found,
now go through all possible connectors, drawing the sprite on
any connected display.

Signed-off-by: Jim Bride 
---
 demos/intel_sprite_on.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/demos/intel_sprite_on.c b/demos/intel_sprite_on.c
index 6ed..ff40e3c 100644
--- a/demos/intel_sprite_on.c
+++ b/demos/intel_sprite_on.c
@@ -563,10 +563,8 @@ static void ricochet(int tiled, int sprite_w, int sprite_h,
 
// Find the native (preferred) display mode
connector_find_preferred_mode(gfx_fd, gfx_resources, 
_connector);
-   if (curr_connector.mode_valid == 0) {
-   printf("No valid preferred mode detected\n");
-   goto out;
-   }
+   if (curr_connector.mode_valid == 0)
+   continue;
 
// Determine if sprite hardware is available on pipe
// associated with this connector.
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH 2/3] drm/i915/gen9: Compute data rates for all planes on first commit

[Daniel Vetter]

On Thu, Jun 09, 2016 at 03:14:54PM -0700, Matt Roper wrote:
> When we sanitize our DDB and watermark info during the first atomic
> commit, we need to calculate the total data rate.  Since we haven't
> explicitly added the planes for each CRTC to our atomic state, the total
> data rate calculation will try to use the cached values from a previous
> commit (which are 0 since there was no previous commit); this result is
> incorrect if we inherited any active planes from the BIOS.
> 
> During our very first atomic commit, we need to explicitly add all
> active planes to the atomic state to ensure that valid data rate values
> are calculated for them.  Subsequent commits will then have valid cached
> values to fall back on.
> 
> Reported-by: Tvrtko Ursulin 
> Cc: Tvrtko Ursulin 
> Signed-off-by: Matt Roper 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 0cd38ca..ba08639 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3933,6 +3933,18 @@ skl_compute_ddb(struct drm_atomic_state *state)
>   if (IS_ERR(cstate))
>   return PTR_ERR(cstate);
>  
> + /*
> +  * If this is our first commit after hw readout, we don't have
> +  * valid data rate values cached.  Add all planes to ensure we
> +  * calculate a valid data rate.
> +  */
> + if (dev_priv->wm.distrust_bios_wm) {
> + ret = drm_atomic_add_affected_planes(state,
> +  _crtc->base);

Again, imo should be pulled out. Other wm code probably has the exact same
bug.
-Daniel

> + if (ret)
> + return ret;
> + }
> +
>   ret = skl_allocate_pipe_ddb(cstate, ddb);
>   if (ret)
>   return ret;
> -- 
> 2.1.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH 1/3] drm/i915/gen9: Initialize intel_state->active_crtcs during WM sanitization

[Daniel Vetter]

On Thu, Jun 09, 2016 at 03:14:53PM -0700, Matt Roper wrote:
> intel_state->active_crtcs is usually only initialized when doing a
> modeset.  During our first atomic commit after boot, we're effectively
> faking a modeset to sanitize the DDB/wm setup, so ensure that this field
> gets initialized before use.
> 
> Reported-by: Tvrtko Ursulin 
> Cc: Tvrtko Ursulin 
> Signed-off-by: Matt Roper 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 658a756..0cd38ca 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3896,9 +3896,18 @@ skl_compute_ddb(struct drm_atomic_state *state)
>* pretend that all pipes switched active status so that we'll
>* ensure a full DDB recompute.
>*/
> - if (dev_priv->wm.distrust_bios_wm)
> + if (dev_priv->wm.distrust_bios_wm) {
>   intel_state->active_pipe_changes = ~0;
>  
> + /*
> +  * We usually only initialize intel_state->active_crtcs if we
> +  * we're doing a modeset; make sure this field is always
> +  * initialized during the sanitization process that happens
> +  * on the first commit too.
> +  */
> + intel_state->active_crtcs = dev_priv->active_crtcs;
> + }

Can't we move input sanitization out of this? Imo mixing up atomic
check/compute config code with hw state restoring is way too fragile.

Also, why exactly do we have active_crtcs? Seems to just be duplicated
state that can get out of sync, we have too many of those already ...
-Daniel

> +
>   /*
>* If the modeset changes which CRTC's are active, we need to
>* recompute the DDB allocation for *all* active pipes, even
> -- 
> 2.1.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH] drm/i915: Force vblanks around evasion when i915.watermark_test is set.

[Daniel Vetter]

On Thu, Jun 09, 2016 at 01:36:50PM +0200, Maarten Lankhorst wrote:
> This will make it more likely that intermediary watermarks cause fifo
> underruns, which is useful when writing watermark specific tests,
> to make it more likely to trigger FIFO underruns in intermediary watermarks.

That's surprising ... with the vblank_wait added you're pretty much
guaranteed to never hit the evasion case. Note that the vblank evasion
code also just does a vblank wait if it detects a possible collision.

Given that I'd have assumed that this simply slows down atomic flips,
which is probably not what we want for testing all. Does this really help?
Any ideas why?
-Daniel

> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/i915_params.c   | 1 +
>  drivers/gpu/drm/i915/i915_params.h   | 1 +
>  drivers/gpu/drm/i915/intel_display.c | 6 ++
>  3 files changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_params.c 
> b/drivers/gpu/drm/i915/i915_params.c
> index 5e18cf9f754d..297d1cd53b15 100644
> --- a/drivers/gpu/drm/i915/i915_params.c
> +++ b/drivers/gpu/drm/i915/i915_params.c
> @@ -45,6 +45,7 @@ struct i915_params i915 __read_mostly = {
>   .fastboot = 0,
>   .prefault_disable = 0,
>   .load_detect_test = 0,
> + .watermark_test = 0,
>   .reset = true,
>   .invert_brightness = 0,
>   .disable_display = 0,
> diff --git a/drivers/gpu/drm/i915/i915_params.h 
> b/drivers/gpu/drm/i915/i915_params.h
> index 1323261a0cdd..91f976c6bac6 100644
> --- a/drivers/gpu/drm/i915/i915_params.h
> +++ b/drivers/gpu/drm/i915/i915_params.h
> @@ -57,6 +57,7 @@ struct i915_params {
>   bool fastboot;
>   bool prefault_disable;
>   bool load_detect_test;
> + bool watermark_test;
>   bool reset;
>   bool disable_display;
>   bool verbose_state_checks;
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 8bb8d36f5cb9..9dcf304c7b1f 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14184,6 +14184,9 @@ static void intel_begin_crtc_commit(struct drm_crtc 
> *crtc,
>   to_intel_crtc_state(old_crtc_state);
>   bool modeset = needs_modeset(crtc->state);
>  
> + if (i915.watermark_test)
> + intel_wait_for_vblank(dev, intel_crtc->pipe);
> +
>   /* Perform vblank evasion around commit operation */
>   intel_pipe_update_start(intel_crtc);
>  
> @@ -14207,6 +14210,9 @@ static void intel_finish_crtc_commit(struct drm_crtc 
> *crtc,
>   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
>  
>   intel_pipe_update_end(intel_crtc, NULL);
> +
> + if (i915.watermark_test)
> + intel_wait_for_vblank(crtc->dev, intel_crtc->pipe);
>  }
>  
>  /**
> -- 
> 2.5.5
> 
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [RESENT PATCH] drm/i915: use #defines for qemu subsystem ids

[Jani Nikula]

On Mon, 13 Jun 2016, Jani Nikula  wrote:
> On Mon, 13 Jun 2016, Gerd Hoffmann  wrote:
>> Signed-off-by: Gerd Hoffmann 
>
> Reviewed-by: Jani Nikula 

And pushed to drm-intel-next-queued, thanks for the patch.

BR,
Jani.

>
>
>> ---
>>  drivers/gpu/drm/i915/i915_drv.c | 6 --
>>  1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_drv.c 
>> b/drivers/gpu/drm/i915/i915_drv.c
>> index f313b4d..3099390 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.c
>> +++ b/drivers/gpu/drm/i915/i915_drv.c
>> @@ -515,8 +515,10 @@ void intel_detect_pch(struct drm_device *dev)
>>  } else if ((id == INTEL_PCH_P2X_DEVICE_ID_TYPE) ||
>> (id == INTEL_PCH_P3X_DEVICE_ID_TYPE) ||
>> ((id == INTEL_PCH_QEMU_DEVICE_ID_TYPE) &&
>> -pch->subsystem_vendor == 0x1af4 &&
>> -pch->subsystem_device == 0x1100)) {
>> +pch->subsystem_vendor ==
>> +PCI_SUBVENDOR_ID_REDHAT_QUMRANET &&
>> +pch->subsystem_device ==
>> +PCI_SUBDEVICE_ID_QEMU)) {
>>  dev_priv->pch_type = intel_virt_detect_pch(dev);
>>  } else
>>  continue;

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

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [1/5] drm/i915: Signal drm events for atomic

[Patchwork]

== Series Details ==

Series: series starting with [1/5] drm/i915: Signal drm events for atomic
URL   : https://patchwork.freedesktop.org/series/8632/
State : failure

== Summary ==

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

Test drv_module_reload_basic:
pass   -> SKIP   (ro-hsw-i3-4010u)
dmesg-warn -> PASS   (fi-skl-i5-6260u)
Test gem_exec_flush:
Subgroup basic-batch-kernel-default-cmd:
pass   -> FAIL   (ro-byt-n2820)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass   -> DMESG-WARN (ro-hsw-i7-4770r)
pass   -> DMESG-WARN (ro-bdw-i7-5600u)
pass   -> DMESG-WARN (ro-hsw-i3-4010u)
pass   -> DMESG-WARN (ro-bdw-i5-5250u)
Subgroup basic-flip-vs-modeset:
pass   -> DMESG-WARN (ro-hsw-i7-4770r)
pass   -> DMESG-WARN (ro-bdw-i7-5600u)
pass   -> DMESG-WARN (ro-hsw-i3-4010u)
pass   -> DMESG-WARN (ro-bdw-i5-5250u)
Subgroup basic-flip-vs-wf_vblank:
pass   -> DMESG-WARN (ro-hsw-i7-4770r)
pass   -> DMESG-WARN (ro-bdw-i5-5250u)
pass   -> DMESG-WARN (ro-hsw-i3-4010u)
pass   -> DMESG-WARN (ro-bdw-i7-5600u)
pass   -> DMESG-WARN (fi-bdw-i7-5557u)
Subgroup basic-plain-flip:
pass   -> DMESG-WARN (ro-hsw-i7-4770r)
pass   -> DMESG-WARN (ro-bdw-i5-5250u)
pass   -> DMESG-WARN (ro-hsw-i3-4010u)
pass   -> DMESG-WARN (ro-bdw-i7-5600u)
pass   -> DMESG-WARN (fi-bdw-i7-5557u)
Test kms_frontbuffer_tracking:
Subgroup basic:
pass   -> DMESG-WARN (ro-hsw-i7-4770r)
pass   -> DMESG-WARN (ro-bdw-i5-5250u)
pass   -> DMESG-WARN (ro-hsw-i3-4010u)
pass   -> DMESG-WARN (ro-bdw-i7-5600u)
pass   -> DMESG-WARN (fi-bdw-i7-5557u)
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-c:
pass   -> DMESG-WARN (ro-ivb2-i7-3770)
Subgroup nonblocking-crc-pipe-c-frame-sequence:
pass   -> SKIP   (fi-skl-i5-6260u)
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> SKIP   (ro-bdw-i5-5250u)

fi-bdw-i7-5557u  total:213  pass:198  dwarn:3   dfail:0   fail:0   skip:12 
fi-skl-i5-6260u  total:213  pass:201  dwarn:0   dfail:0   fail:0   skip:12 
fi-skl-i7-6700k  total:213  pass:188  dwarn:0   dfail:0   fail:0   skip:25 
fi-snb-i7-2600   total:213  pass:174  dwarn:0   dfail:0   fail:0   skip:39 
ro-bdw-i5-5250u  total:213  pass:192  dwarn:6   dfail:0   fail:0   skip:15 
ro-bdw-i7-5600u  total:213  pass:180  dwarn:5   dfail:0   fail:0   skip:28 
ro-bsw-n3050 total:213  pass:171  dwarn:0   dfail:0   fail:2   skip:40 
ro-byt-n2820 total:213  pass:173  dwarn:0   dfail:0   fail:3   skip:37 
ro-hsw-i3-4010u  total:213  pass:184  dwarn:5   dfail:0   fail:0   skip:24 
ro-hsw-i7-4770r  total:213  pass:185  dwarn:5   dfail:0   fail:0   skip:23 
ro-ilk-i7-620lm  total:213  pass:150  dwarn:0   dfail:0   fail:1   skip:62 
ro-ilk1-i5-650   total:208  pass:150  dwarn:0   dfail:0   fail:1   skip:57 
ro-ivb-i7-3770   total:213  pass:181  dwarn:0   dfail:0   fail:0   skip:32 
ro-ivb2-i7-3770  total:213  pass:184  dwarn:1   dfail:0   fail:0   skip:28 
ro-skl3-i5-6260u total:213  pass:201  dwarn:1   dfail:0   fail:0   skip:11 
ro-snb-i7-2620M  total:213  pass:174  dwarn:0   dfail:0   fail:1   skip:38 
fi-hsw-i7-4770k failed to connect after reboot
ro-bdw-i7-5557U failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1177/

9dfa9b5 drm-intel-nightly: 2016y-06m-13d-13h-48m-21s UTC integration manifest
9d5272a drm/i915: Use atomic commits for legacy page_flips
f20c9ba drm/i915: Move fb_bits updating later in atomic_commit
188aae0 drm/i915: nonblocking commit
073e2d3 drm/i915: Roll out the helper nonblock tracking
d4ae869 drm/i915: Signal drm events for atomic

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

Re: [Intel-gfx] [patch] drm/i915/mocs: || vs | typo in get_mocs_settings()

[Mika Kuoppala]

Dan Carpenter  writes:

> It seems pretty clear that bitwise OR was intended here and not logical
> OR.
>
> Fixes: 6fc29133eafb ('drm/i915/gen9: Add WaDisableSkipCaching')
> Signed-off-by: Dan Carpenter 

Pushed to drm-intel-next-queued. Thanks for patch.
-Mika


>
> diff --git a/drivers/gpu/drm/i915/intel_mocs.c 
> b/drivers/gpu/drm/i915/intel_mocs.c
> index 8f96c40..3c1482b 100644
> --- a/drivers/gpu/drm/i915/intel_mocs.c
> +++ b/drivers/gpu/drm/i915/intel_mocs.c
> @@ -162,7 +162,7 @@ static bool get_mocs_settings(struct drm_i915_private 
> *dev_priv,
>  
>   for (i = 0; i < table->size; i++)
>   if (WARN_ON(table->table[i].l3cc_value &
> - (L3_ESC(1) || L3_SCC(0x7
> + (L3_ESC(1) | L3_SCC(0x7
>   return false;
>   }
>  
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/fbc: disable FBC on FIFO underruns

[Zanoni, Paulo R]

Em Seg, 2016-06-13 às 13:47 +0200, Stefan Richter escreveu:
> On Jun 10 Paulo Zanoni wrote:
> > 
> > Since my test machines don't produce FIFO underrun errors, I tested
> > this by
> > creating a debugfs file that just calls
> > intel_fbc_handle_fifo_underrun(). I'd
> > appreciate some Tested-by tags, if possible.
> Since May 8 I have been using 4.6.0-rc6 patched with
> drm-intel-nightly_2016y-05m-06d-14h-29m-58s (from what I understand,
> something close to what is now in mainline), and fbc disabled on the
> kernel commandline.  I have not rebooted since May 8.

Ok, so you're saying that if you boot this Kernel with i915.fbc=1, you
won't get any FIFO underrun messages, but the system is still going to
freeze somehow?

If that's the case, then this patch won't help.

> 
> For that kernel, i915.enable_fbc=0 is both required and sufficient to
> prevent freezes at random points in time (as reported).  The
> drm-intel-nightly_2016y-05m-06d-14h-29m-58s patch on the other hand
> has the
> effect that there are never any FIFO underruns logged anymore.
> 
> If there are no FIFO underruns reported in dmesg, your underrun
> detection routine would never hit, would it?

You're right, there's no need to test on this case.

> 
> If you nevertheless think it's worth trying, should I test it on top
> of
> 4.7-rc3 or on current drm-intel-nightly?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Don't unregister fbdev twice

[Daniel Vetter]

On Wed, Jun 08, 2016 at 07:03:02PM +0200, Lukas Wunner wrote:
> On Wed, Jun 08, 2016 at 02:09:40PM +0200, Daniel Vetter wrote:
> > On Wed, Jun 08, 2016 at 01:15:22PM +0200, Lukas Wunner wrote:
> > > Calling drm_framebuffer_unregister_private() in intel_fbdev_destroy() is
> > > superfluous because the framebuffer will subsequently be unregistered by
> > > drm_framebuffer_free() when unreferenced in drm_framebuffer_remove().
> > > The call is a leftover, when it was introduced by commit 362063619cf6
> > > ("drm: revamp framebuffer cleanup interfaces"), struct intel_framebuffer
> > > was still embedded in struct intel_fbdev rather than being a pointer as
> > > it is today, and drm_framebuffer_remove() wasn't used yet.
> > > 
> > > As a bonus, the ID of the framebuffer is no longer 0 in the debug log:
> > > 
> > > Before:
> > > [   39.680874] [drm:drm_mode_object_unreference] OBJ ID: 0 (3)
> > > [   39.680878] [drm:drm_mode_object_unreference] OBJ ID: 0 (2)
> > > [   39.680884] [drm:drm_mode_object_unreference] OBJ ID: 0 (1)
> > > 
> > > After:
> > > [  102.504649] [drm:drm_mode_object_unreference] OBJ ID: 45 (3)
> > > [  102.504651] [drm:drm_mode_object_unreference] OBJ ID: 45 (2)
> > > [  102.504654] [drm:drm_mode_object_unreference] OBJ ID: 45 (1)
> > > 
> > > Signed-off-by: Lukas Wunner 
> > 
> > Hm yeah. But there's a pile of that particaluar cargo-culting copied all
> > over the place, would be really good to audit all callers of
> > unregister_private and fix them all up. A few older drivers still embed
> > the fbdev fb, but most don't but still use the unregister_private +
> > cleanup combo.
> 
> Yes, I noticed that but i915 was the only one that I could actually test,
> the others I can only compile test. So fixing those up requires very
> careful examination and takes more time, but I'll keep it on my todo list.
> 
> 
> > Nitpick in your subject: s/fbdev/fbdev's fb/
> 
> Right, should I post a v2 or are you going to fix it up if/when merging?

Fixed up while applying - I just waited for CI to get around (and then
w/e). Going through the other drivers to nuke the cargo-culting would
still be awesome.

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

Re: [Intel-gfx] [PATCH 03/12] drm/i915: Add output_types bitmask into the crtc state

[Daniel Vetter]

On Wed, Jun 08, 2016 at 01:41:38PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> Rather than looping through encoders to see which encoder types
> are being driven by the pipe, add an output_types bitmask into
> the crtc state and populate it prior to compute_config and during
> state readout.
> 
> v2: Determine output_types before .compute_config() hooks are called
> 
> Signed-off-by: Ville Syrjälä 

Not sure whether this will mesh with LSPCON perfectly, but the atomic way
is to pass connector_state and crtc_state to all encoder functions. That's
at least how the atomic helpers in the core work, and it imo works well.
i915 isn't there yet, but we want that anyway.

Once you have the connector_state, the connector is just a pointer away.
And the functions which care can look up the connector type.

I'd like to go that direction since it would align i915 more with core
atomic. And that misalignment is imo a big reason for why our transition
is so super painful.
-Daniel

> ---
>  drivers/gpu/drm/i915/intel_display.c | 51 
> +++-
>  drivers/gpu/drm/i915/intel_drv.h |  5 
>  2 files changed, 26 insertions(+), 30 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 12ff79594bc1..eabace447b1c 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -535,14 +535,7 @@ needs_modeset(struct drm_crtc_state *state)
>   */
>  bool intel_pipe_has_type(struct intel_crtc *crtc, enum intel_output_type 
> type)
>  {
> - struct drm_device *dev = crtc->base.dev;
> - struct intel_encoder *encoder;
> -
> - for_each_encoder_on_crtc(dev, >base, encoder)
> - if (encoder->type == type)
> - return true;
> -
> - return false;
> + return crtc->config->output_types & (1 << type);
>  }
>  
>  /**
> @@ -552,28 +545,9 @@ bool intel_pipe_has_type(struct intel_crtc *crtc, enum 
> intel_output_type type)
>   * encoder->crtc.
>   */
>  static bool intel_pipe_will_have_type(const struct intel_crtc_state 
> *crtc_state,
> -   int type)
> +   enum intel_output_type type)
>  {
> - struct drm_atomic_state *state = crtc_state->base.state;
> - struct drm_connector *connector;
> - struct drm_connector_state *connector_state;
> - struct intel_encoder *encoder;
> - int i, num_connectors = 0;
> -
> - for_each_connector_in_state(state, connector, connector_state, i) {
> - if (connector_state->crtc != crtc_state->base.crtc)
> - continue;
> -
> - num_connectors++;
> -
> - encoder = to_intel_encoder(connector_state->best_encoder);
> - if (encoder->type == type)
> - return true;
> - }
> -
> - WARN_ON(num_connectors == 0);
> -
> - return false;
> + return crtc_state->output_types & (1 << type);
>  }
>  
>  /*
> @@ -12529,6 +12503,19 @@ intel_modeset_pipe_config(struct drm_crtc *crtc,
>  _config->pipe_src_w,
>  _config->pipe_src_h);
>  
> + for_each_connector_in_state(state, connector, connector_state, i) {
> + if (connector_state->crtc != crtc)
> + continue;
> +
> + encoder = to_intel_encoder(connector_state->best_encoder);
> +
> + /*
> +  * Determine output_types before calling the .compute_config()
> +  * hooks so that the hooks can use this information safely.
> +  */
> + pipe_config->output_types |= 1 << encoder->type;
> + }
> +
>  encoder_retry:
>   /* Ensure the port clock defaults are reset when retrying. */
>   pipe_config->port_clock = 0;
> @@ -12826,6 +12813,7 @@ intel_pipe_config_compare(struct drm_device *dev,
>   PIPE_CONF_CHECK_M_N_ALT(dp_m_n, dp_m2_n2);
>  
>   PIPE_CONF_CHECK_I(has_dsi_encoder);
> + PIPE_CONF_CHECK_X(output_types);
>  
>   PIPE_CONF_CHECK_I(base.adjusted_mode.crtc_hdisplay);
>   PIPE_CONF_CHECK_I(base.adjusted_mode.crtc_htotal);
> @@ -13093,8 +13081,10 @@ verify_crtc_state(struct drm_crtc *crtc,
>   "Encoder connected to wrong pipe %c\n",
>   pipe_name(pipe));
>  
> - if (active)
> + if (active) {
> + pipe_config->output_types |= 1 << encoder->type;
>   encoder->get_config(encoder, pipe_config);
> + }
>   }
>  
>   if (!new_crtc_state->active)
> @@ -15985,6 +15975,7 @@ static void intel_modeset_readout_hw_state(struct 
> drm_device *dev)
>   if (encoder->get_hw_state(encoder, )) {
>   crtc = 
> to_intel_crtc(dev_priv->pipe_to_crtc_mapping[pipe]);
>   

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [v2,RESEND,1/6] drm/i915/bxt: Wait for PHY1 GRC calibration synchronously

[Patchwork]

== Series Details ==

Series: series starting with [v2,RESEND,1/6] drm/i915/bxt: Wait for PHY1 GRC 
calibration synchronously
URL   : https://patchwork.freedesktop.org/series/8627/
State : failure

== Summary ==

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

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-cmd:
pass   -> FAIL   (ro-byt-n2820)

fi-bdw-i7-5557u  total:213  pass:201  dwarn:0   dfail:0   fail:0   skip:12 
fi-skl-i7-6700k  total:213  pass:188  dwarn:0   dfail:0   fail:0   skip:25 
ro-bdw-i5-5250u  total:213  pass:197  dwarn:2   dfail:0   fail:0   skip:14 
ro-bdw-i7-5557U  total:213  pass:198  dwarn:1   dfail:0   fail:0   skip:14 
ro-bdw-i7-5600u  total:213  pass:185  dwarn:0   dfail:0   fail:0   skip:28 
ro-bsw-n3050 total:213  pass:171  dwarn:1   dfail:0   fail:2   skip:39 
ro-byt-n2820 total:213  pass:173  dwarn:0   dfail:0   fail:3   skip:37 
ro-hsw-i3-4010u  total:213  pass:190  dwarn:0   dfail:0   fail:0   skip:23 
ro-hsw-i7-4770r  total:213  pass:190  dwarn:0   dfail:0   fail:0   skip:23 
ro-ilk-i7-620lm  total:213  pass:150  dwarn:0   dfail:0   fail:1   skip:62 
ro-ilk1-i5-650   total:208  pass:150  dwarn:0   dfail:0   fail:1   skip:57 
ro-ivb-i7-3770   total:213  pass:181  dwarn:0   dfail:0   fail:0   skip:32 
ro-ivb2-i7-3770  total:213  pass:185  dwarn:0   dfail:0   fail:0   skip:28 
ro-skl3-i5-6260u total:213  pass:201  dwarn:1   dfail:0   fail:0   skip:11 
ro-snb-i7-2620M  total:213  pass:174  dwarn:0   dfail:0   fail:1   skip:38 
fi-hsw-i7-4770k failed to connect after reboot
fi-skl-i5-6260u failed to connect after reboot
fi-snb-i7-2600 failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1176/

9dfa9b5 drm-intel-nightly: 2016y-06m-13d-13h-48m-21s UTC integration manifest
361caba drm/i915/bxt: Sanitiy check the PHY lane power down status
ab4f3b4 drm/i915/bxt: Rename broxton to bxt in PHY/CDCLK function prefixes
d130ab9 drm/i915/bxt: Set DDI PHY lane latency optimization during modeset
aeba9cb drm/i915/bxt: Move DDI PHY enabling/disabling to the power well code
4d8024d drm/i915: Factor out intel_power_well_get/put
db93190 drm/i915/bxt: Wait for PHY1 GRC calibration synchronously

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Crop cursor image for CHV pipe C cursor issue

[Daniel Vetter]

On Fri, Jun 10, 2016 at 03:14:36PM +0530, Agrawal, Akshu wrote:
> On 6/8/2016 2:10 PM, Daniel Vetter wrote:
> > On Wed, Jun 08, 2016 at 01:57:44PM +0530, Akshu Agrawal wrote:
> > > CHV pipe C hits underrun when we get -ve X values of cursor. To avoid
> > > this we crop the cursor image for by -ve X value and thus use '0' as
> > > least X value.
> > 
> > You're talking about "-ve" here and there's absolutely no "-ve" anywhere
> > in your patch. That makes your commit message non-understandable.
> 
> Will change -ve to "negative" for better readability.
> 
> > 
> > But I think I get what you're doing here, and nope, you can't override the
> > cursor image like that. If we go with this w/a then you need to allocate a
> > new cursor gem bo instead. This is userspace-visible.
> 
> Can't we use the same gem bo? As we are calling
> "i915_gem_object_set_to_gtt_domain" to get write access for CPU after
> unbinding from GTT.

Userspace can write to the underlying bo without telling us. That'll cause
tearing. And it could also read from it, which would result in even more
serious bugs.

We can't just change userspace-visible state for a w/a. Same reasoning
applies to the crtc_state stuff. Again we need copies, to avoid
accidentally confusion userspace.

With all those copies it's probably best to write a special
atomic_update_plane function for cursor pipe C, to avoid spreading all of
them all over the driver.
-Daniel

> 
> Regards,
> Akshu
> > 
> > For similar reasons you're also not allowed to change crtc->state.
> > -Daniel
> > 
> > > Signed-off-by: Akshu Agrawal 
> > > ---
> > >  drivers/gpu/drm/i915/intel_display.c | 113 
> > > +++
> > >  drivers/gpu/drm/i915/intel_drv.h |   3 +
> > >  2 files changed, 116 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index bca9245..e6e6568 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -14279,6 +14279,81 @@ void intel_create_rotation_property(struct 
> > > drm_device *dev, struct intel_plane *
> > >   plane->base.state->rotation);
> > >  }
> > > 
> > > +static void vlv_unpin_buffer_obj(struct drm_i915_gem_object *obj,
> > > +   char __iomem *buffer_start)
> > > +{
> > > + iounmap(buffer_start);
> > > + i915_gem_object_ggtt_unpin(obj);
> > > +}
> > > +
> > > +static char __iomem *vlv_pin_and_map_buffer_obj
> > > + (struct drm_i915_gem_object *obj)
> > > +{
> > > + struct drm_i915_private *dev_priv = obj->base.dev->dev_private;
> > > + char __iomem *buffer_start;
> > > + int ret;
> > > +
> > > + ret = i915_gem_obj_ggtt_pin(obj, PAGE_SIZE, PIN_MAPPABLE);
> > > + if (ret)
> > > + return NULL;
> > > +
> > > + ret = i915_gem_object_set_to_gtt_domain(obj, true);
> > > + if (ret) {
> > > + i915_gem_object_ggtt_unpin(obj);
> > > + return NULL;
> > > + }
> > > +
> > > + buffer_start = ioremap_wc(dev_priv->gtt.mappable_base +
> > > + i915_gem_obj_ggtt_offset(obj), obj->base.size);
> > > + if (buffer_start == NULL) {
> > > + i915_gem_object_ggtt_unpin(obj);
> > > + return NULL;
> > > + }
> > > +
> > > + return buffer_start;
> > > +}
> > > +
> > > +static int vlv_cursor_crop(struct intel_plane_state *state,
> > > +   int prev_x)
> > > +{
> > > + struct drm_i915_gem_object *obj = intel_fb_obj(state->base.fb);
> > > + struct drm_framebuffer *fb = state->base.fb;
> > > + char __iomem *buffer = state->vlv_cursor_image;
> > > + char __iomem *base, *cursor_base;
> > > + int size = obj->base.size;
> > > + int i, x = state->base.crtc_x;
> > > + int bytes_per_pixel = fb->bits_per_pixel / 8;
> > > +
> > > + base = vlv_pin_and_map_buffer_obj(obj);
> > > + if (base == NULL)
> > > + return -ENOMEM;
> > > +
> > > + if (prev_x >= 0) {
> > > + if (buffer != NULL)
> > > + kfree(buffer);
> > > + buffer = kzalloc(size, GFP_KERNEL);
> > > + state->vlv_cursor_image = buffer;
> > > + if (buffer == NULL)
> > > + return -ENOMEM;
> > > + memcpy(buffer, base, size);
> > > + }
> > > + cursor_base = buffer;
> > > + x = -x;
> > > + for (i = 0; i < state->base.crtc_h; i++) {
> > > + cursor_base += x * bytes_per_pixel;
> > > + memcpy(base, cursor_base,
> > > + (state->base.crtc_w - x) * bytes_per_pixel);
> > > + base += (state->base.crtc_w - x) * bytes_per_pixel;
> > > + memset(base, 0, x * bytes_per_pixel);
> > > + base += x * bytes_per_pixel;
> > > + cursor_base += (state->base.crtc_w - x) * bytes_per_pixel;
> > > + }
> > > +
> > > + vlv_unpin_buffer_obj(obj, base);
> > > +
> > > + return 0;
> > > +}
> > > +
> > >  static int
> > >  intel_check_cursor_plane(struct drm_plane *plane,
> > >struct 

Re: [Intel-gfx] [PATCH 29/38] drm/i915: Remove locking for get_tiling

[Daniel Vetter]

On Wed, Jun 08, 2016 at 11:11:07AM +0100, Chris Wilson wrote:
> On Wed, Jun 08, 2016 at 12:02:01PM +0200, Daniel Vetter wrote:
> > On Fri, Jun 03, 2016 at 05:55:44PM +0100, Chris Wilson wrote:
> > > Since we are not concerned with userspace racing itself with set-tiling
> > > (the order is indeterminant even if we take a lock), then we can safely
> > > read back the single obj->tiling_mode and do the static lookup of
> > > swizzle mode without having to take a lock.
> > > 
> > > get-tiling is reasonably frequent due to the back-channel passing around
> > > of tiling parameters in DRI2/DRI3.
> > > 
> > > Signed-off-by: Chris Wilson 
> > > ---
> > >  drivers/gpu/drm/i915/i915_gem_tiling.c | 8 ++--
> > >  1 file changed, 2 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_gem_tiling.c 
> > > b/drivers/gpu/drm/i915/i915_gem_tiling.c
> > > index 326de7eae101..d6acd0a27c06 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem_tiling.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem_tiling.c
> > > @@ -302,10 +302,8 @@ i915_gem_get_tiling(struct drm_device *dev, void 
> > > *data,
> > >   if (!obj)
> > >   return -ENOENT;
> > >  
> > > - mutex_lock(>struct_mutex);
> > > -
> > >   args->tiling_mode = obj->tiling_mode;
> > 
> > READ_ONCE here. With that Reviewed-by: Daniel Vetter 
> > 
> 
> obj->tiling_mode is still a bitfield. Not yet convinced of extracting
> it, but avoiding the lock for get_tiling is useful.

With all the recent discussions the past years about gcc becoming more and
more creative with exploiting the undefined parts of C99 I'm just a bit
paranoid. Would be awesome if we could unbitfield this one beforehand ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 3/5] drm/i915: nonblocking commit

[Daniel Vetter]

Simply split intel_atomic_commit in half and place the new
nonblocking commit helpers at the right spots.

NOTE: There's still trouble with obj->frontbuffer bits getting mangled
when pipelining atomic commits.

v2:
- Remove the check for nonblocking which returned -EINVAL.
- Do wait for requests in the worker thread before committing
  hw state.

v3: Move hw_done after the optimize_wm/post_plane_update step, plus
add FIXME comment how to fix that up again properly.

v4: Update FIXME for intel_atomic_commit - more stuff works now.

v5: Still reject nonblocking modeset commits (Maarten).

Cc: Maarten Lankhorst 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_display.c | 126 ---
 1 file changed, 87 insertions(+), 39 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index d68ca2825cd7..a16a307dbb76 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13544,12 +13544,12 @@ static int intel_atomic_prepare_commit(struct 
drm_device *dev,
struct drm_crtc *crtc;
int i, ret;
 
-   if (nonblock) {
-   DRM_DEBUG_KMS("i915 does not yet support nonblocking commit\n");
-   return -EINVAL;
-   }
-
for_each_crtc_in_state(state, crtc, crtc_state, i) {
+   if (needs_modeset(crtc_state) && nonblock) {
+   DRM_DEBUG_KMS("nonblocking commit for modeset not yet 
implemented.\n");
+   return -EINVAL;
+   }
+
if (state->legacy_cursor_update)
continue;
 
@@ -13667,50 +13667,34 @@ static bool needs_vblank_wait(struct intel_crtc_state 
*crtc_state)
return false;
 }
 
-/**
- * intel_atomic_commit - commit validated state object
- * @dev: DRM device
- * @state: the top-level driver state object
- * @nonblock: nonblocking commit
- *
- * This function commits a top-level state object that has been validated
- * with drm_atomic_helper_check().
- *
- * FIXME:  Atomic modeset support for i915 is not yet complete.  At the moment
- * we can only handle plane-related operations and do not yet support
- * nonblocking commit.
- *
- * RETURNS
- * Zero for success or -errno.
- */
-static int intel_atomic_commit(struct drm_device *dev,
-  struct drm_atomic_state *state,
-  bool nonblock)
+static void intel_atomic_commit_tail(struct drm_atomic_state *state)
 {
+   struct drm_device *dev = state->dev;
struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
struct drm_i915_private *dev_priv = dev->dev_private;
struct drm_crtc_state *old_crtc_state;
struct drm_crtc *crtc;
struct intel_crtc_state *intel_cstate;
-   int ret = 0, i;
+   struct drm_plane *plane;
+   struct drm_plane_state *plane_state;
bool hw_check = intel_state->modeset;
unsigned long put_domains[I915_MAX_PIPES] = {};
unsigned crtc_vblank_mask = 0;
+   int i, ret;
 
-   ret = drm_atomic_helper_setup_commit(state, nonblock);
-   if (ret)
-   return ret;
+   for_each_plane_in_state(state, plane, plane_state, i) {
+   struct intel_plane_state *intel_plane_state =
+   to_intel_plane_state(plane_state);
 
-   ret = intel_atomic_prepare_commit(dev, state, nonblock);
-   if (ret) {
-   DRM_DEBUG_ATOMIC("Preparing state failed with %i\n", ret);
-   return ret;
-   }
+   if (!intel_plane_state->wait_req)
+   continue;
 
-   drm_atomic_helper_swap_state(state, true);
-   dev_priv->wm.distrust_bios_wm = false;
-   dev_priv->wm.skl_results = intel_state->wm_results;
-   intel_shared_dpll_commit(state);
+   ret = __i915_wait_request(intel_plane_state->wait_req,
+ true, NULL, NULL);
+   /* EIO should be eaten, and we can't get interrupted in the
+* worker, and blocking commits have waited already. */
+   WARN_ON(ret);
+   }
 
drm_atomic_helper_wait_for_dependencies(state);
 
@@ -13809,8 +13793,15 @@ static int intel_atomic_commit(struct drm_device *dev,
crtc_vblank_mask |= 1 << i;
}
 
-   drm_atomic_helper_commit_hw_done(state);
-
+   /* FIXME: We should call drm_atomic_helper_commit_hw_done() here
+* already, but still need the state for the delayed optimization. To
+* fix this:
+* - wrap the optimization/post_plane_update stuff into a per-crtc work.
+* - schedule that vblank worker _before_ calling hw_done
+* - at the start of commit_tail, cancel it _synchrously
+* - switch over to the vblank wait helper in the core after that since
+*   we don't 

[Intel-gfx] [PATCH 4/5] drm/i915: Move fb_bits updating later in atomic_commit

[Daniel Vetter]

Currently it's part of prepare_fb, still in the first phase of
atomic_commit which might fail. Which means that we need to have some
heuristics in cleanup_fb to figure out whether things failed, or
whether we just clean up the old fbs.

That's fragile, and worse, once we start pipelining commits gets
confused: While the last commit is still getting cleanup up we already
hammer in the new one, and fb_bits aren't refcounted, resulting in
lost bits and WARN_ON galore. We could instead try to make cleanup_fb
more clever, but a simpler fix is to postpone the fb_bits tracking
past the point of no return, where we commit all the software state.

That also makes conceptually more sense, since fb_bits must be updated
synchronously from the ioctl (they track usage from userspace pov, not
from the hw pov), right before we're fully committed to the updated.

This fixes WARNING splats from track_fb with page_flip implemented
through atomic_commit.

Testcase: igt/kms_flip/flip-vs-rmfb
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_display.c | 41 ++--
 1 file changed, 25 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a16a307dbb76..fd46db4882e5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13863,6 +13863,25 @@ static void intel_atomic_commit_work(struct 
work_struct *work)
intel_atomic_commit_tail(state);
 }
 
+static void intel_atomic_track_fbs(struct drm_atomic_state *state)
+{
+   struct drm_plane_state *old_plane_state;
+   struct drm_plane *plane;
+   struct drm_i915_gem_object *obj, *old_obj;
+   struct intel_plane *intel_plane;
+   int i;
+
+   mutex_lock(>dev->struct_mutex);
+   for_each_plane_in_state(state, plane, old_plane_state, i) {
+   obj = intel_fb_obj(plane->state->fb);
+   old_obj = intel_fb_obj(old_plane_state->fb);
+   intel_plane = to_intel_plane(plane);
+
+   i915_gem_track_fb(old_obj, obj, intel_plane->frontbuffer_bit);
+   }
+   mutex_unlock(>dev->struct_mutex);
+}
+
 /**
  * intel_atomic_commit - commit validated state object
  * @dev: DRM device
@@ -13903,6 +13922,7 @@ static int intel_atomic_commit(struct drm_device *dev,
dev_priv->wm.distrust_bios_wm = false;
dev_priv->wm.skl_results = intel_state->wm_results;
intel_shared_dpll_commit(state);
+   intel_atomic_track_fbs(state);
 
if (nonblock)
queue_work(system_unbound_wq, >commit_work);
@@ -13982,7 +14002,6 @@ intel_prepare_plane_fb(struct drm_plane *plane,
 {
struct drm_device *dev = plane->dev;
struct drm_framebuffer *fb = new_state->fb;
-   struct intel_plane *intel_plane = to_intel_plane(plane);
struct drm_i915_gem_object *obj = intel_fb_obj(fb);
struct drm_i915_gem_object *old_obj = intel_fb_obj(plane->state->fb);
int ret = 0;
@@ -14039,16 +14058,12 @@ intel_prepare_plane_fb(struct drm_plane *plane,
ret = intel_pin_and_fence_fb_obj(fb, new_state->rotation);
}
 
-   if (ret == 0) {
-   if (obj) {
-   struct intel_plane_state *plane_state =
-   to_intel_plane_state(new_state);
-
-   i915_gem_request_assign(_state->wait_req,
-   obj->last_write_req);
-   }
+   if (ret == 0 && obj) {
+   struct intel_plane_state *plane_state =
+   to_intel_plane_state(new_state);
 
-   i915_gem_track_fb(old_obj, obj, intel_plane->frontbuffer_bit);
+   i915_gem_request_assign(_state->wait_req,
+   obj->last_write_req);
}
 
return ret;
@@ -14068,7 +14083,6 @@ intel_cleanup_plane_fb(struct drm_plane *plane,
   const struct drm_plane_state *old_state)
 {
struct drm_device *dev = plane->dev;
-   struct intel_plane *intel_plane = to_intel_plane(plane);
struct intel_plane_state *old_intel_state;
struct drm_i915_gem_object *old_obj = intel_fb_obj(old_state->fb);
struct drm_i915_gem_object *obj = intel_fb_obj(plane->state->fb);
@@ -14082,11 +14096,6 @@ intel_cleanup_plane_fb(struct drm_plane *plane,
!INTEL_INFO(dev)->cursor_needs_physical))
intel_unpin_fb_obj(old_state->fb, old_state->rotation);
 
-   /* prepare_fb aborted? */
-   if ((old_obj && (old_obj->frontbuffer_bits & 
intel_plane->frontbuffer_bit)) ||
-   (obj && !(obj->frontbuffer_bits & intel_plane->frontbuffer_bit)))
-   i915_gem_track_fb(old_obj, obj, intel_plane->frontbuffer_bit);
-
i915_gem_request_assign(_intel_state->wait_req, NULL);
 }
 
-- 
2.8.1

___
Intel-gfx mailing list

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

[Daniel Vetter]

Note that I didn't start garbage collecting all the legacy flip code
yet, to make it easier to revert this. But there will be _lots_ of
code that can be removed once this is tested on all platforms.

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

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index fd46db4882e5..de1ff4a85b5e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11619,6 +11619,7 @@ void intel_check_page_flip(struct drm_i915_private 
*dev_priv, int pipe)
spin_unlock(>event_lock);
 }
 
+__attribute__((unused))
 static int intel_crtc_page_flip(struct drm_crtc *crtc,
struct drm_framebuffer *fb,
struct drm_pending_vblank_event *event,
@@ -13977,7 +13978,7 @@ static const struct drm_crtc_funcs intel_crtc_funcs = {
.set_config = drm_atomic_helper_set_config,
.set_property = drm_atomic_helper_crtc_set_property,
.destroy = intel_crtc_destroy,
-   .page_flip = intel_crtc_page_flip,
+   .page_flip = drm_atomic_helper_page_flip,
.atomic_duplicate_state = intel_crtc_duplicate_state,
.atomic_destroy_state = intel_crtc_destroy_state,
 };
-- 
2.8.1

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

[Intel-gfx] [PATCH 2/5] drm/i915: Roll out the helper nonblock tracking

[Daniel Vetter]

Right now still all blocking, no worker anywhere to be seen.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_display.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a4ebf9df7dc3..d68ca2825cd7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13697,6 +13697,10 @@ static int intel_atomic_commit(struct drm_device *dev,
unsigned long put_domains[I915_MAX_PIPES] = {};
unsigned crtc_vblank_mask = 0;
 
+   ret = drm_atomic_helper_setup_commit(state, nonblock);
+   if (ret)
+   return ret;
+
ret = intel_atomic_prepare_commit(dev, state, nonblock);
if (ret) {
DRM_DEBUG_ATOMIC("Preparing state failed with %i\n", ret);
@@ -13708,6 +13712,8 @@ static int intel_atomic_commit(struct drm_device *dev,
dev_priv->wm.skl_results = intel_state->wm_results;
intel_shared_dpll_commit(state);
 
+   drm_atomic_helper_wait_for_dependencies(state);
+
if (intel_state->modeset) {
memcpy(dev_priv->min_pixclk, intel_state->min_pixclk,
   sizeof(intel_state->min_pixclk));
@@ -13803,7 +13809,7 @@ static int intel_atomic_commit(struct drm_device *dev,
crtc_vblank_mask |= 1 << i;
}
 
-   /* FIXME: add subpixel order */
+   drm_atomic_helper_commit_hw_done(state);
 
if (!state->legacy_cursor_update)
intel_atomic_wait_for_vblanks(dev, dev_priv, crtc_vblank_mask);
@@ -13838,6 +13844,8 @@ static int intel_atomic_commit(struct drm_device *dev,
drm_atomic_helper_cleanup_planes(dev, state);
mutex_unlock(>struct_mutex);
 
+   drm_atomic_helper_commit_cleanup_done(state);
+
drm_atomic_state_free(state);
 
/* As one of the primary mmio accessors, KMS has a high likelihood
-- 
2.8.1

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

[Intel-gfx] [PATCH 1/5] drm/i915: Signal drm events for atomic

[Daniel Vetter]

This is part of what atomic must implement. And it's also required
to be able to use the helper nonblocking support.

v2: Always send out the drm event, remove the planes_changed check.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_display.c | 13 ++---
 drivers/gpu/drm/i915/intel_sprite.c  | 14 ++
 2 files changed, 24 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 801e4c17dd8d..a4ebf9df7dc3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13774,13 +13774,21 @@ static int intel_atomic_commit(struct drm_device *dev,
bool modeset = needs_modeset(crtc->state);
struct intel_crtc_state *pipe_config =
to_intel_crtc_state(crtc->state);
-   bool update_pipe = !modeset && pipe_config->update_pipe;
 
if (modeset && crtc->state->active) {
update_scanline_offset(to_intel_crtc(crtc));
dev_priv->display.crtc_enable(crtc);
}
 
+   /* Complete events for now disable pipes here. */
+   if (modeset && !crtc->state->active && crtc->state->event) {
+   spin_lock_irq(>event_lock);
+   drm_crtc_send_vblank_event(crtc, crtc->state->event);
+   spin_unlock_irq(>event_lock);
+
+   crtc->state->event = NULL;
+   }
+
if (!modeset)

intel_pre_plane_update(to_intel_crtc_state(old_crtc_state));
 
@@ -13788,8 +13796,7 @@ static int intel_atomic_commit(struct drm_device *dev,
drm_atomic_get_existing_plane_state(state, crtc->primary))
intel_fbc_enable(intel_crtc);
 
-   if (crtc->state->active &&
-   (crtc->state->planes_changed || update_pipe))
+   if (crtc->state->active)
drm_atomic_helper_commit_planes_on_crtc(old_crtc_state);
 
if (pipe_config->base.active && needs_vblank_wait(pipe_config))
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index 324ccb06397d..fc654173c491 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -166,6 +166,20 @@ void intel_pipe_update_end(struct intel_crtc *crtc, struct 
intel_flip_work *work
 
trace_i915_pipe_update_end(crtc, end_vbl_count, scanline_end);
 
+   /* We're still in the vblank-evade critical section, this can't race.
+* Would be slightly nice to just grab the vblank count and arm the
+* event outside of the critical section - the spinlock might spin for a
+* while ... */
+   if (crtc->base.state->event) {
+   WARN_ON(drm_crtc_vblank_get(>base) != 0);
+
+   spin_lock(>base.dev->event_lock);
+   drm_crtc_arm_vblank_event(>base, crtc->base.state->event);
+   spin_unlock(>base.dev->event_lock);
+
+   crtc->base.state->event = NULL;
+   }
+
local_irq_enable();
 
if (crtc->debug.start_vbl_count &&
-- 
2.8.1

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

Re: [Intel-gfx] ✗ Ro.CI.BAT: warning for drm/i915/gen9: implement WaConextSwitchWithConcurrentTLBInvalidate (rev3)

[Tvrtko Ursulin]

On 13/06/16 14:35, Gore, Tim wrote:



Tim Gore
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ


-Original Message-
From: Patchwork [mailto:patchw...@emeril.freedesktop.org]
Sent: Monday, June 13, 2016 12:40 PM
To: Gore, Tim
Cc: intel-gfx@lists.freedesktop.org
Subject: ✗ Ro.CI.BAT: warning for drm/i915/gen9: implement
WaConextSwitchWithConcurrentTLBInvalidate (rev3)

== Series Details ==

Series: drm/i915/gen9: implement
WaConextSwitchWithConcurrentTLBInvalidate (rev3)
URL   : https://patchwork.freedesktop.org/series/8487/
State : warning

== Summary ==

Series 8487v3 drm/i915/gen9: implement
WaConextSwitchWithConcurrentTLBInvalidate
http://patchwork.freedesktop.org/api/1.0/series/8487/revisions/3/mbox

Test gem_exec_flush:
 Subgroup basic-batch-kernel-default-cmd:
 fail   -> PASS   (ro-byt-n2820)
Test gem_exec_suspend:
 Subgroup basic-s3:
 pass   -> DMESG-WARN (ro-bdw-i7-5557U)


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


Test kms_force_connector_basic:
 Subgroup force-connector-state:
 skip   -> PASS   (ro-ivb2-i7-3770)
 Subgroup force-edid:
 skip   -> PASS   (ro-ivb2-i7-3770)
 Subgroup prune-stale-modes:
 skip   -> PASS   (ro-ivb2-i7-3770)
Test kms_pipe_crc_basic:
 Subgroup nonblocking-crc-pipe-b:
 pass   -> SKIP   (fi-skl-i5-6260u)
 Subgroup suspend-read-crc-pipe-b:
 skip   -> DMESG-WARN (ro-bdw-i7-5557U)


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


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

fi-bdw-i7-5557u  total:213  pass:201  dwarn:0   dfail:0   fail:0   skip:12
fi-skl-i5-6260u  total:213  pass:201  dwarn:0   dfail:0   fail:0   skip:12
fi-skl-i7-6700k  total:213  pass:188  dwarn:0   dfail:0   fail:0   skip:25
fi-snb-i7-2600   total:213  pass:174  dwarn:0   dfail:0   fail:0   skip:39
ro-bdw-i5-5250u  total:213  pass:197  dwarn:1   dfail:0   fail:0   skip:15
ro-bdw-i7-5557U  total:213  pass:197  dwarn:2   dfail:0   fail:0   skip:14
ro-bdw-i7-5600u  total:213  pass:185  dwarn:0   dfail:0   fail:0   skip:28
ro-bsw-n3050 total:213  pass:172  dwarn:0   dfail:0   fail:2   skip:39
ro-byt-n2820 total:213  pass:174  dwarn:0   dfail:0   fail:2   skip:37
ro-hsw-i3-4010u  total:213  pass:190  dwarn:0   dfail:0   fail:0   skip:23
ro-hsw-i7-4770r  total:213  pass:190  dwarn:0   dfail:0   fail:0   skip:23
ro-ilk-i7-620lm  total:213  pass:150  dwarn:0   dfail:0   fail:1   skip:62
ro-ilk1-i5-650   total:208  pass:150  dwarn:0   dfail:0   fail:1   skip:57
ro-ivb-i7-3770   total:213  pass:181  dwarn:0   dfail:0   fail:0   skip:32
ro-ivb2-i7-3770  total:213  pass:185  dwarn:0   dfail:0   fail:0   skip:28
ro-skl3-i5-6260u total:213  pass:201  dwarn:1   dfail:0   fail:0   skip:11
ro-snb-i7-2620M  total:213  pass:174  dwarn:0   dfail:0   fail:1   skip:38
fi-hsw-i7-4770k failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1171/

f80cfb4 drm-intel-nightly: 2016y-06m-13d-10h-41m-19s UTC integration
manifest 3f1502e drm/i915/gen9: implement
WaConextSwitchWithConcurrentTLBInvalidate


Merged, thanks for the patch and review.

Regards,

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

[Intel-gfx] [PATCH i-g-t 2/2] tests/kms_rmfb: Use for_each_pipe_with_valid_output.

[Maarten Lankhorst]

Signed-off-by: Maarten Lankhorst 
---
 tests/kms_rmfb.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/tests/kms_rmfb.c b/tests/kms_rmfb.c
index a3fde9f43788..89aa323210dd 100644
--- a/tests/kms_rmfb.c
+++ b/tests/kms_rmfb.c
@@ -144,12 +144,9 @@ run_rmfb_test(struct rmfb_data *data, bool reopen)
int valid_tests = 0;
enum pipe pipe;
 
-   for_each_connected_output(>display, output) {
-   for_each_pipe(>display, pipe) {
-   if (test_rmfb(data, output, pipe, reopen))
-   valid_tests++;
-   }
-   }
+   for_each_pipe_with_valid_output(>display, pipe, output)
+   if (test_rmfb(data, output, pipe, reopen))
+   valid_tests++;
 
igt_require_f(valid_tests, "no valid crtc/connector combinations 
found\n");
 }
-- 
2.5.5

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

[Intel-gfx] [PATCH i-g-t 1/2] lib/igt_kms: Add for_each_pipe_with_valid_output and for_each_valid_output_on_pipe.

[Maarten Lankhorst]

There are a lot of places where we do either

for_each_pipe {
igt_subtest_f(... "-pipe-C", pipe_name())
for_each_connected_output()
/* Run subtest */
}

or:
igt_subtest_f(...) {
for_each_pipe()
for_each_connected_output()
/* Run subtest */
}

The former should be replaced with for_each_valid_output_on_pipe,
the latter with for_each_pipe_with_valid_output.

Signed-off-by: Maarten Lankhorst 
---
 lib/igt_kms.c | 29 -
 lib/igt_kms.h | 23 ++-
 2 files changed, 38 insertions(+), 14 deletions(-)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index af72b90800e4..f9e32a5a2e3d 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -773,8 +773,8 @@ static bool _kmstest_connector_config(int drm_fd, uint32_t 
connector_id,
 {
drmModeRes *resources;
drmModeConnector *connector;
-   drmModeEncoder *encoder;
-   int i, j;
+   drmModeEncoder *encoder, *found = NULL;
+   int i, j, pipe;
 
resources = drmModeGetResources(drm_fd);
if (!resources) {
@@ -810,9 +810,9 @@ static bool _kmstest_connector_config(int drm_fd, uint32_t 
connector_id,
 * In both cases find the first compatible encoder and skip the CRTC
 * if there is non such.
 */
-   encoder = NULL; /* suppress GCC warning */
+   config->valid_crtc_idx_mask = 0;
for (i = 0; i < resources->count_crtcs; i++) {
-   if (!resources->crtcs[i] || !(crtc_idx_mask & (1 << i)))
+   if (!resources->crtcs[i])
continue;
 
/* Now get a compatible encoder */
@@ -828,24 +828,27 @@ static bool _kmstest_connector_config(int drm_fd, 
uint32_t connector_id,
continue;
}
 
-   if (encoder->possible_crtcs & (1 << i))
-   goto found;
+   config->valid_crtc_idx_mask |= encoder->possible_crtcs;
 
-   drmModeFreeEncoder(encoder);
+   if (!found && (crtc_idx_mask & encoder->possible_crtcs 
& (1 << i))) {
+   found = encoder;
+   pipe = i;
+   } else
+   drmModeFreeEncoder(encoder);
}
}
 
-   goto err3;
+   if (!found)
+   goto err3;
 
-found:
if (!kmstest_get_connector_default_mode(drm_fd, connector,
>default_mode))
goto err4;
 
config->connector = connector;
-   config->encoder = encoder;
-   config->crtc = drmModeGetCrtc(drm_fd, resources->crtcs[i]);
-   config->crtc_idx = i;
+   config->encoder = found;
+   config->crtc = drmModeGetCrtc(drm_fd, resources->crtcs[pipe]);
+   config->crtc_idx = pipe;
config->pipe = kmstest_get_pipe_from_crtc_id(drm_fd,
 config->crtc->crtc_id);
 
@@ -853,7 +856,7 @@ found:
 
return true;
 err4:
-   drmModeFreeEncoder(encoder);
+   drmModeFreeEncoder(found);
 err3:
drmModeFreeConnector(connector);
 err2:
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 7aad8c8c2153..b66743a29027 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -114,6 +114,7 @@ struct kmstest_connector_config {
uint32_t atomic_props_connector[IGT_NUM_CONNECTOR_PROPS];
int crtc_idx;
int pipe;
+   unsigned valid_crtc_idx_mask;
 };
 
 /**
@@ -327,13 +328,33 @@ void igt_fb_set_size(struct igt_fb *fb, igt_plane_t 
*plane,
 
 void igt_wait_for_vblank(int drm_fd, enum pipe pipe);
 
+static inline bool igt_pipe_connector_valid(enum pipe pipe,
+   igt_output_t *output)
+{
+   return output->valid && (output->config.valid_crtc_idx_mask & (1 << 
pipe));
+}
+
+#define for_each_if(condition) if (!(condition)) {} else
+
 #define for_each_connected_output(display, output) \
for (int i__ = 0;  i__ < (display)->n_outputs; i__++)   \
-   if ((output = &(display)->outputs[i__]), output->valid)
+   for_each_if (((output = &(display)->outputs[i__]), 
output->valid))
 
 #define for_each_pipe(display, pipe)   \
for (pipe = 0; pipe < igt_display_get_n_pipes(display); pipe++) \
 
+/* Big complex macro to make 'break' work as expected. */
+#define for_each_pipe_with_valid_output(display, pipe, output) \
+   for (int con__ = pipe = 0; \
+pipe < igt_display_get_n_pipes((display)) && con__ < 
(display)->n_outputs; \
+con__ = (con__ + 1 < (display)->n_outputs) ? con__ + 1 : (pipe = 
pipe + 1, 0)) \
+   for_each_if (((output = &(display)->outputs[con__]), \
+igt_pipe_connector_valid(pipe, 

Re: [Intel-gfx] [PATCH i-g-t 2/2] tests/kms_chv_cursor_fail: Run the tests with fewer steps.

[Maarten Lankhorst]

Op 08-06-16 om 16:52 schreef Ville Syrjälä:
> On Wed, Jun 08, 2016 at 04:47:48PM +0200, Maarten Lankhorst wrote:
>> Op 08-06-16 om 15:35 schreef Ville Syrjälä:
>>> On Wed, Jun 08, 2016 at 03:23:33PM +0200, Maarten Lankhorst wrote:
 Op 08-06-16 om 15:12 schreef Ville Syrjälä:
> On Wed, Jun 08, 2016 at 01:25:32PM +0200, Maarten Lankhorst wrote:
>> This reduces the runtime of the tests from ~200s on my 30 fps 4k panel
>> to 10s.
> Does it still find the problem reliably on CHV pipe C (if you remove the
> kernel w/a)?
 Yeah, a single coordinate is enough to trigger the fifo underrun. Rest is 
 probably still slightly overkill. :)
>>> Hmm. IIRC it wasn't quite that easy to trigger on my CHV. Sometime
>>> it survived for a few iterations. But I'm too lazy to retest it now,
>>> so I'll take your word for it.
>>>
>> Weird, even kms_cursor_crc random test triggered it for me on the first try 
>> with negative coordinates.
> Might be that I'm only recalling the visual feedback. That is, maybe I
> sometimes failed to see the underrun even though it did happen.
>
Can I take this as a r-b?

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

[Intel-gfx] [PATCH v2 RESEND 3/6] drm/i915/bxt: Move DDI PHY enabling/disabling to the power well code

[Imre Deak]

So far we depended on the HW to dynamically power down unused PHYs and
so we enabled them manually once during driver loading/resuming. There
are indications however that we can achieve better power savings by
manual powering toggling. So make the PHY enabling/disabling to happen
on-demand whenever we need either the corresponding AUX or port
functionality. CHV does this already by enabling the PHY along the
corresponding PHY common lane power wells there, do the same on BXT by
adding virtual power wells for the same purpose.

Also sanity check the common lane power down ack signal from the PHY. Do
this only when the PHY is enabled, since it's not clear at what point
the HW power/clock gates things.

While at it rename broxton_ prefix to bxt_ in related function names to
better align with the SKL code.

Signed-off-by: Imre Deak 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_reg.h |   3 +
 drivers/gpu/drm/i915/intel_ddi.c|  46 +++---
 drivers/gpu/drm/i915/intel_drv.h|   9 ++-
 drivers/gpu/drm/i915/intel_runtime_pm.c | 106 +---
 4 files changed, 117 insertions(+), 47 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 81d1896..6caa5ab 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -716,6 +716,9 @@ enum skl_disp_power_wells {
/* Not actual bit groups. Used as IDs for lookup_power_well() */
SKL_DISP_PW_ALWAYS_ON,
SKL_DISP_PW_DC_OFF,
+
+   BXT_DPIO_CMN_A,
+   BXT_DPIO_CMN_BC,
 };
 
 #define SKL_POWER_WELL_STATE(pw) (1 << ((pw) * 2))
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index b10c7b5..dee6dd0 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1742,8 +1742,8 @@ static void intel_disable_ddi(struct intel_encoder 
*intel_encoder)
}
 }
 
-static bool broxton_phy_is_enabled(struct drm_i915_private *dev_priv,
-  enum dpio_phy phy)
+bool bxt_ddi_phy_is_enabled(struct drm_i915_private *dev_priv,
+   enum dpio_phy phy)
 {
if (!(I915_READ(BXT_P_CR_GT_DISP_PWRON) & GT_DISPLAY_POWER_ON(phy)))
return false;
@@ -1787,21 +1787,17 @@ static void broxton_phy_wait_grc_done(struct 
drm_i915_private *dev_priv,
DRM_ERROR("timeout waiting for PHY%d GRC\n", phy);
 }
 
-static bool broxton_phy_verify_state(struct drm_i915_private *dev_priv,
-enum dpio_phy phy);
-
-static void broxton_phy_init(struct drm_i915_private *dev_priv,
-enum dpio_phy phy)
+void bxt_ddi_phy_init(struct drm_i915_private *dev_priv, enum dpio_phy phy)
 {
enum port port;
u32 ports, val;
 
-   if (broxton_phy_is_enabled(dev_priv, phy)) {
+   if (bxt_ddi_phy_is_enabled(dev_priv, phy)) {
/* Still read out the GRC value for state verification */
if (phy == DPIO_PHY0)
dev_priv->bxt_phy_grc = broxton_get_grc(dev_priv, phy);
 
-   if (broxton_phy_verify_state(dev_priv, phy)) {
+   if (bxt_ddi_phy_verify_state(dev_priv, phy)) {
DRM_DEBUG_DRIVER("DDI PHY %d already enabled, "
 "won't reprogram it\n", phy);
 
@@ -1810,8 +1806,6 @@ static void broxton_phy_init(struct drm_i915_private 
*dev_priv,
 
DRM_DEBUG_DRIVER("DDI PHY %d enabled with invalid state, "
 "force reprogramming it\n", phy);
-   } else {
-   DRM_DEBUG_DRIVER("DDI PHY %d not enabled, enabling it\n", phy);
}
 
val = I915_READ(BXT_P_CR_GT_DISP_PWRON);
@@ -1919,15 +1913,7 @@ static void broxton_phy_init(struct drm_i915_private 
*dev_priv,
broxton_phy_wait_grc_done(dev_priv, DPIO_PHY1);
 }
 
-void broxton_ddi_phy_init(struct drm_i915_private *dev_priv)
-{
-   /* Enable PHY1 first since it provides Rcomp for PHY0 */
-   broxton_phy_init(dev_priv, DPIO_PHY1);
-   broxton_phy_init(dev_priv, DPIO_PHY0);
-}
-
-static void broxton_phy_uninit(struct drm_i915_private *dev_priv,
-  enum dpio_phy phy)
+void bxt_ddi_phy_uninit(struct drm_i915_private *dev_priv, enum dpio_phy phy)
 {
uint32_t val;
 
@@ -1940,12 +1926,6 @@ static void broxton_phy_uninit(struct drm_i915_private 
*dev_priv,
I915_WRITE(BXT_P_CR_GT_DISP_PWRON, val);
 }
 
-void broxton_ddi_phy_uninit(struct drm_i915_private *dev_priv)
-{
-   broxton_phy_uninit(dev_priv, DPIO_PHY1);
-   broxton_phy_uninit(dev_priv, DPIO_PHY0);
-}
-
 static bool __printf(6, 7)
 __phy_reg_verify_state(struct drm_i915_private *dev_priv, enum dpio_phy phy,
   i915_reg_t reg, u32 mask, u32 expected,
@@ -1973,8 +1953,8 @@ __phy_reg_verify_state(struct 

[Intel-gfx] [PATCH v2 RESEND 5/6] drm/i915/bxt: Rename broxton to bxt in PHY/CDCLK function prefixes

[Imre Deak]

Rename these remaining function prefixes to better align with the
corresponding SKL functions.

No functional change.

Signed-off-by: Imre Deak 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_ddi.c| 13 ++---
 drivers/gpu/drm/i915/intel_display.c| 28 ++--
 drivers/gpu/drm/i915/intel_drv.h|  4 ++--
 drivers/gpu/drm/i915/intel_runtime_pm.c |  4 ++--
 4 files changed, 24 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index e7edeec..cb48b0d 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1773,15 +1773,15 @@ bool bxt_ddi_phy_is_enabled(struct drm_i915_private 
*dev_priv,
return true;
 }
 
-static u32 broxton_get_grc(struct drm_i915_private *dev_priv, enum dpio_phy 
phy)
+static u32 bxt_get_grc(struct drm_i915_private *dev_priv, enum dpio_phy phy)
 {
u32 val = I915_READ(BXT_PORT_REF_DW6(phy));
 
return (val & GRC_CODE_MASK) >> GRC_CODE_SHIFT;
 }
 
-static void broxton_phy_wait_grc_done(struct drm_i915_private *dev_priv,
- enum dpio_phy phy)
+static void bxt_phy_wait_grc_done(struct drm_i915_private *dev_priv,
+ enum dpio_phy phy)
 {
if (wait_for(I915_READ(BXT_PORT_REF_DW3(phy)) & GRC_DONE, 10))
DRM_ERROR("timeout waiting for PHY%d GRC\n", phy);
@@ -1794,7 +1794,7 @@ void bxt_ddi_phy_init(struct drm_i915_private *dev_priv, 
enum dpio_phy phy)
if (bxt_ddi_phy_is_enabled(dev_priv, phy)) {
/* Still read out the GRC value for state verification */
if (phy == DPIO_PHY0)
-   dev_priv->bxt_phy_grc = broxton_get_grc(dev_priv, phy);
+   dev_priv->bxt_phy_grc = bxt_get_grc(dev_priv, phy);
 
if (bxt_ddi_phy_verify_state(dev_priv, phy)) {
DRM_DEBUG_DRIVER("DDI PHY %d already enabled, "
@@ -1870,8 +1870,7 @@ void bxt_ddi_phy_init(struct drm_i915_private *dev_priv, 
enum dpio_phy phy)
 * the corresponding calibrated value from PHY1, and disable
 * the automatic calibration on PHY0.
 */
-   val = dev_priv->bxt_phy_grc = broxton_get_grc(dev_priv,
- DPIO_PHY1);
+   val = dev_priv->bxt_phy_grc = bxt_get_grc(dev_priv, DPIO_PHY1);
grc_code = val << GRC_CODE_FAST_SHIFT |
   val << GRC_CODE_SLOW_SHIFT |
   val;
@@ -1887,7 +1886,7 @@ void bxt_ddi_phy_init(struct drm_i915_private *dev_priv, 
enum dpio_phy phy)
I915_WRITE(BXT_PHY_CTL_FAMILY(phy), val);
 
if (phy == DPIO_PHY1)
-   broxton_phy_wait_grc_done(dev_priv, DPIO_PHY1);
+   bxt_phy_wait_grc_done(dev_priv, DPIO_PHY1);
 }
 
 void bxt_ddi_phy_uninit(struct drm_i915_private *dev_priv, enum dpio_phy phy)
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index c0edb4b..37dd345 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -123,7 +123,7 @@ static void ironlake_pfit_enable(struct intel_crtc *crtc);
 static void intel_modeset_setup_hw_state(struct drm_device *dev);
 static void intel_pre_disable_primary_noatomic(struct drm_crtc *crtc);
 static int ilk_max_pixel_rate(struct drm_atomic_state *state);
-static int broxton_calc_cdclk(int max_pixclk);
+static int bxt_calc_cdclk(int max_pixclk);
 
 struct intel_limit {
struct {
@@ -5420,7 +5420,7 @@ static void bxt_de_pll_enable(struct drm_i915_private 
*dev_priv, int vco)
dev_priv->cdclk_pll.vco = vco;
 }
 
-static void broxton_set_cdclk(struct drm_i915_private *dev_priv, int cdclk)
+static void bxt_set_cdclk(struct drm_i915_private *dev_priv, int cdclk)
 {
u32 val, divider;
int vco, ret;
@@ -5545,7 +5545,7 @@ sanitize:
dev_priv->cdclk_pll.vco = -1;
 }
 
-void broxton_init_cdclk(struct drm_i915_private *dev_priv)
+void bxt_init_cdclk(struct drm_i915_private *dev_priv)
 {
bxt_sanitize_cdclk(dev_priv);
 
@@ -5557,12 +5557,12 @@ void broxton_init_cdclk(struct drm_i915_private 
*dev_priv)
 * - The initial CDCLK needs to be read from VBT.
 *   Need to make this change after VBT has changes for BXT.
 */
-   broxton_set_cdclk(dev_priv, broxton_calc_cdclk(0));
+   bxt_set_cdclk(dev_priv, bxt_calc_cdclk(0));
 }
 
-void broxton_uninit_cdclk(struct drm_i915_private *dev_priv)
+void bxt_uninit_cdclk(struct drm_i915_private *dev_priv)
 {
-   broxton_set_cdclk(dev_priv, dev_priv->cdclk_pll.ref);
+   bxt_set_cdclk(dev_priv, dev_priv->cdclk_pll.ref);
 }
 
 static int skl_calc_cdclk(int max_pixclk, int vco)
@@ -5988,7 +5988,7 @@ static int valleyview_calc_cdclk(struct drm_i915_private 
*dev_priv,
 

[Intel-gfx] [PATCH v2 RESEND 2/6] drm/i915: Factor out intel_power_well_get/put

[Imre Deak]

These helpers will be needed by the next patch, so factor them out.

No functional change.

v2:
- Move the refcount==0 WARN to the new put helper. (Ville)

CC: Ville Syrjälä 
Signed-off-by: Imre Deak 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_runtime_pm.c | 33 +
 1 file changed, 21 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 2b75b30..10978cb 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -151,6 +151,23 @@ static void intel_power_well_disable(struct 
drm_i915_private *dev_priv,
power_well->ops->disable(dev_priv, power_well);
 }
 
+static void intel_power_well_get(struct drm_i915_private *dev_priv,
+struct i915_power_well *power_well)
+{
+   if (!power_well->count++)
+   intel_power_well_enable(dev_priv, power_well);
+}
+
+static void intel_power_well_put(struct drm_i915_private *dev_priv,
+struct i915_power_well *power_well)
+{
+   WARN(!power_well->count, "Use count on power well %s is already zero",
+power_well->name);
+
+   if (!--power_well->count)
+   intel_power_well_disable(dev_priv, power_well);
+}
+
 /*
  * We should only use the power well if we explicitly asked the hardware to
  * enable it, so check if it's enabled and also check if we've requested it to
@@ -1518,10 +1535,8 @@ __intel_display_power_get_domain(struct drm_i915_private 
*dev_priv,
struct i915_power_well *power_well;
int i;
 
-   for_each_power_well(i, power_well, BIT(domain), power_domains) {
-   if (!power_well->count++)
-   intel_power_well_enable(dev_priv, power_well);
-   }
+   for_each_power_well(i, power_well, BIT(domain), power_domains)
+   intel_power_well_get(dev_priv, power_well);
 
power_domains->domain_use_count[domain]++;
 }
@@ -1615,14 +1630,8 @@ void intel_display_power_put(struct drm_i915_private 
*dev_priv,
 intel_display_power_domain_str(domain));
power_domains->domain_use_count[domain]--;
 
-   for_each_power_well_rev(i, power_well, BIT(domain), power_domains) {
-   WARN(!power_well->count,
-"Use count on power well %s is already zero",
-power_well->name);
-
-   if (!--power_well->count)
-   intel_power_well_disable(dev_priv, power_well);
-   }
+   for_each_power_well_rev(i, power_well, BIT(domain), power_domains)
+   intel_power_well_put(dev_priv, power_well);
 
mutex_unlock(_domains->lock);
 
-- 
2.5.0

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

[Intel-gfx] [PATCH v2 RESEND 4/6] drm/i915/bxt: Set DDI PHY lane latency optimization during modeset

[Imre Deak]

So far we configured a static lane latency optimization during driver
loading/resuming. The specification changed at one point and now this
configuration depends on the lane count, so move the configuration
to modeset time accordingly.

It's not clear when this lane configuration takes effect. The
specification only requires that the programming is done before enabling
the port. On CHV OTOH the lanes start to power up already right after
enabling the PLL. To be safe preserve the current order and set things
up already before enabling the PLL.

v2: (Ander)
- Simplify the optimization mask calculation.
- Use the correct pipe_config always during the calculation instead
  of the bogus intel_crtc->config.

CC: Ander Conselvan de Oliveira 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95476
Signed-off-by: Imre Deak 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_ddi.c | 123 +++
 drivers/gpu/drm/i915/intel_display.c |   5 ++
 drivers/gpu/drm/i915/intel_drv.h |   6 ++
 3 files changed, 91 insertions(+), 43 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index dee6dd0..e7edeec 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1789,8 +1789,7 @@ static void broxton_phy_wait_grc_done(struct 
drm_i915_private *dev_priv,
 
 void bxt_ddi_phy_init(struct drm_i915_private *dev_priv, enum dpio_phy phy)
 {
-   enum port port;
-   u32 ports, val;
+   u32 val;
 
if (bxt_ddi_phy_is_enabled(dev_priv, phy)) {
/* Still read out the GRC value for state verification */
@@ -1825,28 +1824,6 @@ void bxt_ddi_phy_init(struct drm_i915_private *dev_priv, 
enum dpio_phy phy)
DRM_ERROR("timeout during PHY%d power on\n", phy);
}
 
-   if (phy == DPIO_PHY0)
-   ports = BIT(PORT_B) | BIT(PORT_C);
-   else
-   ports = BIT(PORT_A);
-
-   for_each_port_masked(port, ports) {
-   int lane;
-
-   for (lane = 0; lane < 4; lane++) {
-   val = I915_READ(BXT_PORT_TX_DW14_LN(port, lane));
-   /*
-* Note that on CHV this flag is called UPAR, but has
-* the same function.
-*/
-   val &= ~LATENCY_OPTIM;
-   if (lane != 1)
-   val |= LATENCY_OPTIM;
-
-   I915_WRITE(BXT_PORT_TX_DW14_LN(port, lane), val);
-   }
-   }
-
/* Program PLL Rcomp code offset */
val = I915_READ(BXT_PORT_CL1CM_DW9(phy));
val &= ~IREF0RC_OFFSET_MASK;
@@ -1956,8 +1933,6 @@ __phy_reg_verify_state(struct drm_i915_private *dev_priv, 
enum dpio_phy phy,
 bool bxt_ddi_phy_verify_state(struct drm_i915_private *dev_priv,
  enum dpio_phy phy)
 {
-   enum port port;
-   u32 ports;
uint32_t mask;
bool ok;
 
@@ -1970,21 +1945,6 @@ bool bxt_ddi_phy_verify_state(struct drm_i915_private 
*dev_priv,
 
ok = true;
 
-   if (phy == DPIO_PHY0)
-   ports = BIT(PORT_B) | BIT(PORT_C);
-   else
-   ports = BIT(PORT_A);
-
-   for_each_port_masked(port, ports) {
-   int lane;
-
-   for (lane = 0; lane < 4; lane++)
-   ok &= _CHK(BXT_PORT_TX_DW14_LN(port, lane),
-   LATENCY_OPTIM,
-   lane != 1 ? LATENCY_OPTIM : 0,
-   "BXT_PORT_TX_DW14_LN(%d, %d)", port, lane);
-   }
-
/* PLL Rcomp code offset */
ok &= _CHK(BXT_PORT_CL1CM_DW9(phy),
IREF0RC_OFFSET_MASK, 0xe4 << IREF0RC_OFFSET_SHIFT,
@@ -2028,6 +1988,67 @@ bool bxt_ddi_phy_verify_state(struct drm_i915_private 
*dev_priv,
 #undef _CHK
 }
 
+static uint8_t
+bxt_ddi_phy_calc_lane_lat_optim_mask(struct intel_encoder *encoder,
+struct intel_crtc_state *pipe_config)
+{
+   switch (pipe_config->lane_count) {
+   case 1:
+   return 0;
+   case 2:
+   return BIT(2) | BIT(0);
+   case 4:
+   return BIT(3) | BIT(2) | BIT(0);
+   default:
+   MISSING_CASE(pipe_config->lane_count);
+
+   return 0;
+   }
+}
+
+static void bxt_ddi_pre_pll_enable(struct intel_encoder *encoder)
+{
+   struct intel_digital_port *dport = enc_to_dig_port(>base);
+   struct drm_i915_private *dev_priv = to_i915(dport->base.base.dev);
+   enum port port = dport->port;
+   struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
+   int lane;
+
+   for (lane = 0; lane < 4; lane++) {
+   u32 val = I915_READ(BXT_PORT_TX_DW14_LN(port, lane));
+
+   /*
+* 

[Intel-gfx] [PATCH v2 RESEND 6/6] drm/i915/bxt: Sanitiy check the PHY lane power down status

[Imre Deak]

We can check the power state of the PHY data and common lanes as
reported by the PHY. Do this in case we need to debug problems where the
PHY gets stuck in an unexpected state.

Note that I only check these when the lanes are expected to be powered
on purpose, since it's not clear at what point the PHY power/clock gates
things.

v2:
- Don't report the encoder as disabled when the sanity check fails.
  (Ville)

CC: Ville Syrjälä 
Signed-off-by: Imre Deak 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_reg.h  |  9 +
 drivers/gpu/drm/i915/intel_ddi.c | 25 +
 2 files changed, 34 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 6caa5ab..4807f38 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1279,6 +1279,15 @@ enum skl_disp_power_wells {
 #define BXT_P_CR_GT_DISP_PWRON _MMIO(0x138090)
 #define   GT_DISPLAY_POWER_ON(phy) (1 << (phy))
 
+#define _BXT_PHY_CTL_DDI_A 0x64C00
+#define _BXT_PHY_CTL_DDI_B 0x64C10
+#define _BXT_PHY_CTL_DDI_C 0x64C20
+#define   BXT_PHY_CMNLANE_POWERDOWN_ACK(1 << 10)
+#define   BXT_PHY_LANE_POWERDOWN_ACK   (1 << 9)
+#define   BXT_PHY_LANE_ENABLED (1 << 8)
+#define BXT_PHY_CTL(port)  _MMIO_PORT(port, _BXT_PHY_CTL_DDI_A, \
+_BXT_PHY_CTL_DDI_B)
+
 #define _PHY_CTL_FAMILY_EDP0x64C80
 #define _PHY_CTL_FAMILY_DDI0x64C90
 #define   COMMON_RESET_DIS (1 << 31)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index cb48b0d..bd0c46a 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1342,6 +1342,14 @@ bool intel_ddi_get_hw_state(struct intel_encoder 
*encoder,
DRM_DEBUG_KMS("No pipe for ddi port %c found\n", port_name(port));
 
 out:
+   if (ret && IS_BROXTON(dev_priv)) {
+   tmp = I915_READ(BXT_PHY_CTL(port));
+   if ((tmp & (BXT_PHY_LANE_POWERDOWN_ACK |
+   BXT_PHY_LANE_ENABLED)) != BXT_PHY_LANE_ENABLED)
+   DRM_ERROR("Port %c enabled but PHY powered down? "
+ "(PHY_CTL %08x)\n", port_name(port), tmp);
+   }
+
intel_display_power_put(dev_priv, power_domain);
 
return ret;
@@ -1745,6 +1753,8 @@ static void intel_disable_ddi(struct intel_encoder 
*intel_encoder)
 bool bxt_ddi_phy_is_enabled(struct drm_i915_private *dev_priv,
enum dpio_phy phy)
 {
+   enum port port;
+
if (!(I915_READ(BXT_P_CR_GT_DISP_PWRON) & GT_DISPLAY_POWER_ON(phy)))
return false;
 
@@ -1770,6 +1780,21 @@ bool bxt_ddi_phy_is_enabled(struct drm_i915_private 
*dev_priv,
return false;
}
 
+   for_each_port_masked(port,
+phy == DPIO_PHY0 ? BIT(PORT_B) | BIT(PORT_C) :
+   BIT(PORT_A)) {
+   u32 tmp = I915_READ(BXT_PHY_CTL(port));
+
+   if (tmp & BXT_PHY_CMNLANE_POWERDOWN_ACK) {
+   DRM_DEBUG_DRIVER("DDI PHY %d powered, but common lane "
+"for port %c powered down "
+"(PHY_CTL %08x)\n",
+phy, port_name(port), tmp);
+
+   return false;
+   }
+   }
+
return true;
 }
 
-- 
2.5.0

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

[Intel-gfx] [PATCH v2 RESEND 1/6] drm/i915/bxt: Wait for PHY1 GRC calibration synchronously

[Imre Deak]

A follow-up patch moves the PHY enabling to the power well code where
enabling/disabling the PHYs will happen independently. Because of this
waiting for the GRC calibration in PHY1 asynchronously would need some
additional logic. Instead of adding that let's keep things simple for now
and wait synchronously. My measurements showed that the calibration
takes ~4ms.

Signed-off-by: Imre Deak 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_ddi.c | 15 +++
 1 file changed, 3 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 022b41d..b10c7b5 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1899,8 +1899,6 @@ static void broxton_phy_init(struct drm_i915_private 
*dev_priv,
 * the corresponding calibrated value from PHY1, and disable
 * the automatic calibration on PHY0.
 */
-   broxton_phy_wait_grc_done(dev_priv, DPIO_PHY1);
-
val = dev_priv->bxt_phy_grc = broxton_get_grc(dev_priv,
  DPIO_PHY1);
grc_code = val << GRC_CODE_FAST_SHIFT |
@@ -1912,14 +1910,13 @@ static void broxton_phy_init(struct drm_i915_private 
*dev_priv,
val |= GRC_DIS | GRC_RDY_OVRD;
I915_WRITE(BXT_PORT_REF_DW8(DPIO_PHY0), val);
}
-   /*
-* During PHY1 init delay waiting for GRC calibration to finish, since
-* it can happen in parallel with the subsequent PHY0 init.
-*/
 
val = I915_READ(BXT_PHY_CTL_FAMILY(phy));
val |= COMMON_RESET_DIS;
I915_WRITE(BXT_PHY_CTL_FAMILY(phy), val);
+
+   if (phy == DPIO_PHY1)
+   broxton_phy_wait_grc_done(dev_priv, DPIO_PHY1);
 }
 
 void broxton_ddi_phy_init(struct drm_i915_private *dev_priv)
@@ -1927,12 +1924,6 @@ void broxton_ddi_phy_init(struct drm_i915_private 
*dev_priv)
/* Enable PHY1 first since it provides Rcomp for PHY0 */
broxton_phy_init(dev_priv, DPIO_PHY1);
broxton_phy_init(dev_priv, DPIO_PHY0);
-
-   /*
-* If BIOS enabled only PHY0 and not PHY1, we skipped waiting for the
-* PHY1 GRC calibration to finish, so wait for it here.
-*/
-   broxton_phy_wait_grc_done(dev_priv, DPIO_PHY1);
 }
 
 static void broxton_phy_uninit(struct drm_i915_private *dev_priv,
-- 
2.5.0

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

Re: [Intel-gfx] ✗ Ro.CI.BAT: warning for drm/i915/gen9: implement WaConextSwitchWithConcurrentTLBInvalidate (rev3)

[Gore, Tim]

Tim Gore 
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ

> -Original Message-
> From: Patchwork [mailto:patchw...@emeril.freedesktop.org]
> Sent: Monday, June 13, 2016 12:40 PM
> To: Gore, Tim
> Cc: intel-gfx@lists.freedesktop.org
> Subject: ✗ Ro.CI.BAT: warning for drm/i915/gen9: implement
> WaConextSwitchWithConcurrentTLBInvalidate (rev3)
> 
> == Series Details ==
> 
> Series: drm/i915/gen9: implement
> WaConextSwitchWithConcurrentTLBInvalidate (rev3)
> URL   : https://patchwork.freedesktop.org/series/8487/
> State : warning
> 
> == Summary ==
> 
> Series 8487v3 drm/i915/gen9: implement
> WaConextSwitchWithConcurrentTLBInvalidate
> http://patchwork.freedesktop.org/api/1.0/series/8487/revisions/3/mbox
> 
> Test gem_exec_flush:
> Subgroup basic-batch-kernel-default-cmd:
> fail   -> PASS   (ro-byt-n2820)
> Test gem_exec_suspend:
> Subgroup basic-s3:
> pass   -> DMESG-WARN (ro-bdw-i7-5557U)

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

> Test kms_force_connector_basic:
> Subgroup force-connector-state:
> skip   -> PASS   (ro-ivb2-i7-3770)
> Subgroup force-edid:
> skip   -> PASS   (ro-ivb2-i7-3770)
> Subgroup prune-stale-modes:
> skip   -> PASS   (ro-ivb2-i7-3770)
> Test kms_pipe_crc_basic:
> Subgroup nonblocking-crc-pipe-b:
> pass   -> SKIP   (fi-skl-i5-6260u)
> Subgroup suspend-read-crc-pipe-b:
> skip   -> DMESG-WARN (ro-bdw-i7-5557U)

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

> Subgroup suspend-read-crc-pipe-c:
> dmesg-warn -> SKIP   (ro-bdw-i5-5250u)
> 
> fi-bdw-i7-5557u  total:213  pass:201  dwarn:0   dfail:0   fail:0   skip:12
> fi-skl-i5-6260u  total:213  pass:201  dwarn:0   dfail:0   fail:0   skip:12
> fi-skl-i7-6700k  total:213  pass:188  dwarn:0   dfail:0   fail:0   skip:25
> fi-snb-i7-2600   total:213  pass:174  dwarn:0   dfail:0   fail:0   skip:39
> ro-bdw-i5-5250u  total:213  pass:197  dwarn:1   dfail:0   fail:0   skip:15
> ro-bdw-i7-5557U  total:213  pass:197  dwarn:2   dfail:0   fail:0   skip:14
> ro-bdw-i7-5600u  total:213  pass:185  dwarn:0   dfail:0   fail:0   skip:28
> ro-bsw-n3050 total:213  pass:172  dwarn:0   dfail:0   fail:2   skip:39
> ro-byt-n2820 total:213  pass:174  dwarn:0   dfail:0   fail:2   skip:37
> ro-hsw-i3-4010u  total:213  pass:190  dwarn:0   dfail:0   fail:0   skip:23
> ro-hsw-i7-4770r  total:213  pass:190  dwarn:0   dfail:0   fail:0   skip:23
> ro-ilk-i7-620lm  total:213  pass:150  dwarn:0   dfail:0   fail:1   skip:62
> ro-ilk1-i5-650   total:208  pass:150  dwarn:0   dfail:0   fail:1   skip:57
> ro-ivb-i7-3770   total:213  pass:181  dwarn:0   dfail:0   fail:0   skip:32
> ro-ivb2-i7-3770  total:213  pass:185  dwarn:0   dfail:0   fail:0   skip:28
> ro-skl3-i5-6260u total:213  pass:201  dwarn:1   dfail:0   fail:0   skip:11
> ro-snb-i7-2620M  total:213  pass:174  dwarn:0   dfail:0   fail:1   skip:38
> fi-hsw-i7-4770k failed to connect after reboot
> 
> Results at /archive/results/CI_IGT_test/RO_Patchwork_1171/
> 
> f80cfb4 drm-intel-nightly: 2016y-06m-13d-10h-41m-19s UTC integration
> manifest 3f1502e drm/i915/gen9: implement
> WaConextSwitchWithConcurrentTLBInvalidate

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

Re: [Intel-gfx] [PATCH 7/7] drm/i915: Allow DP ports to set/readout infoframe state (WIP)

[Sharma, Shashank]

Regards
Shashank

On 6/3/2016 1:25 AM, ville.syrj...@linux.intel.com wrote:

From: Ville Syrjälä 

The video DIP can be used with DP ports as well. So let's at least read
out the state, and disable all infoframes when disabling the port.
Otherwise we might get left with whatever the previous guy was doing.

If we were totally paranaoid, I suppose we might consider doing this
for FDI too on DDI platforms. But that would require first decoupling
the infoframe code from intel_digital_port. So leave it be for now at
least.

FIXME need to figure out how to handle the PSR VSC SDP usage before
doing this, as that might make the state checker unhappy.

Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/i915/intel_ddi.c | 13 -
  drivers/gpu/drm/i915/intel_dp.c  |  9 +
  2 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index c5611e9d9b9c..6543feeb58f2 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2157,7 +2157,6 @@ void intel_ddi_get_config(struct intel_encoder *encoder,
struct drm_i915_private *dev_priv = encoder->base.dev->dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
enum transcoder cpu_transcoder = pipe_config->cpu_transcoder;
-   struct intel_digital_port *intel_dig_port;
u32 temp, flags = 0;

/* XXX: DSI transcoder paranoia */
@@ -2193,13 +2192,17 @@ void intel_ddi_get_config(struct intel_encoder *encoder,
break;
}

-   switch (temp & TRANS_DDI_MODE_SELECT_MASK) {
-   case TRANS_DDI_MODE_SELECT_HDMI:
-   pipe_config->has_hdmi_sink = true;
-   intel_dig_port = enc_to_dig_port(>base);
+   if (encoder->type != INTEL_OUTPUT_ANALOG) {
This will be true for INTEL_OUTPUT_UNUSED, UNKNOWN, eDP, and bunch of 
more encoder types. Should we add a bit mask for valid encoder types here ?

+   struct intel_digital_port *intel_dig_port =
+   enc_to_dig_port(>base);

if (intel_dig_port->infoframe_enabled(>base, 
pipe_config))
pipe_config->has_infoframe = true;
+   }
+
+   switch (temp & TRANS_DDI_MODE_SELECT_MASK) {
+   case TRANS_DDI_MODE_SELECT_HDMI:
+   pipe_config->has_hdmi_sink = true;
/* fall through */
case TRANS_DDI_MODE_SELECT_DVI:
pipe_config->lane_count = 4;
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index a2d0ee363307..b43009ed1dab 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2355,6 +2355,7 @@ static void intel_dp_get_config(struct intel_encoder 
*encoder,
struct intel_crtc_state *pipe_config)
  {
struct intel_dp *intel_dp = enc_to_intel_dp(>base);
+   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
u32 tmp, flags = 0;
struct drm_device *dev = encoder->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -2395,6 +2396,10 @@ static void intel_dp_get_config(struct intel_encoder 
*encoder,
!IS_CHERRYVIEW(dev) && tmp & DP_COLOR_RANGE_16_235)
pipe_config->limited_color_range = true;

+   if (intel_dig_port->infoframe_enabled &&
+   intel_dig_port->infoframe_enabled(>base, pipe_config))
+   pipe_config->has_infoframe = true;
+
pipe_config->has_dp_encoder = true;

pipe_config->lane_count =
@@ -3343,6 +3348,10 @@ intel_dp_link_down(struct intel_dp *intel_dp)
intel_set_pch_fifo_underrun_reporting(dev_priv, PIPE_A, true);
}

+   if (intel_dig_port->set_infoframes)
+   intel_dig_port->set_infoframes(_dig_port->base.base,
+  NULL, false);
+
msleep(intel_dp->panel_power_down_delay);

intel_dp->DP = DP;


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

Re: [Intel-gfx] [PATCH] drm/i915: pwrite/pread do not require obj->base.filp, just pages

[Chris Wilson]

On Mon, Jun 13, 2016 at 02:12:46PM +0100, Tvrtko Ursulin wrote:
> 
> On 13/06/16 13:52, Chris Wilson wrote:
> >On Mon, Jun 13, 2016 at 01:45:56PM +0100, Tvrtko Ursulin wrote:
> >>
> >>On 13/06/16 13:40, Chris Wilson wrote:
> >>>The idea behind relaxing the restriction for pread/pwrite was to handle
> >>>!obj->base.flip, i.e. non-shmemfs backed objects, which only requires
> >>>that the object provide struct pages.
> >>>
> >>>v2: Remove excess (). Note enough editing after copy'n'paste.
> >>>
> >>>Signed-off-by: Chris Wilson 
> >>>Cc: Ankitprasad Sharma 
> >>>Cc: Tvrtko Ursulin 
> >>>---
> >>>  drivers/gpu/drm/i915/i915_gem.c | 7 ---
> >>>  1 file changed, 4 insertions(+), 3 deletions(-)
> >>>
> >>>diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> >>>b/drivers/gpu/drm/i915/i915_gem.c
> >>>index 21d0dea57312..6f950c37efab 100644
> >>>--- a/drivers/gpu/drm/i915/i915_gem.c
> >>>+++ b/drivers/gpu/drm/i915/i915_gem.c
> >>>@@ -760,7 +760,7 @@ i915_gem_shmem_pread(struct drm_device *dev,
> >>>   int needs_clflush = 0;
> >>>   struct sg_page_iter sg_iter;
> >>>
> >>>-  if (!obj->base.filp)
> >>>+  if ((obj->ops->flags & I915_GEM_OBJECT_HAS_STRUCT_PAGE) == 0)
> >>>   return -ENODEV;
> >>>
> >>>   user_data = u64_to_user_ptr(args->data_ptr);
> >>>@@ -1298,7 +1298,8 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void 
> >>>*data,
> >>>* pread/pwrite currently are reading and writing from the CPU
> >>>* perspective, requiring manual detiling by the client.
> >>>*/
> >>>-  if (!obj->base.filp || cpu_write_needs_clflush(obj)) {
> >>>+  if ((obj->ops->flags & I915_GEM_OBJECT_HAS_STRUCT_PAGE) == 0 ||
> >>>+  cpu_write_needs_clflush(obj)) {
> >>>   ret = i915_gem_gtt_pwrite_fast(dev_priv, obj, args, file);
> >>>   /* Note that the gtt paths might fail with non-page-backed user
> >>>* pointers (e.g. gtt mappings when moving data between
> >>>@@ -1308,7 +1309,7 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void 
> >>>*data,
> >>>   if (ret == -EFAULT) {
> >>>   if (obj->phys_handle)
> >>>   ret = i915_gem_phys_pwrite(obj, args, file);
> >>>-  else if (obj->base.filp)
> >>>+  else if (obj->ops->flags & I915_GEM_OBJECT_HAS_STRUCT_PAGE)
> >>>   ret = i915_gem_shmem_pwrite(dev, obj, args, file);
> >>>   else
> >>>   ret = -ENODEV;
> >>>
> >>
> >>To enable on userptr or there is more to it? Would it even make more
> >>sense to keep rejecting it on userptr to discourage suboptimal
> >>userspace?
> >
> >And prime objects, and everything in future not backed by a filp.
> 
> Hmm.. I sense a hole in the IGT coverage. :)
> 
> You definitely do not mind allowing it with userptr?

Don't mind. People shouldn't use it, but I'd rather have fewer special
cases in the ABI.
 
> Actually, we don't need to go through the aperture for anything but
> stolen, right? A third, more optimal path could be added for page
> backed objects which are not shmem, not userptr and not stolen.

Hence s/obj->base.filp/obj->op->flags & HAS_STRUCT_PAGE/. The shmem path
is for direct access to struct page, everything else requires
indirect access through the GTT.

In the future, we may want indirect access through another set of pfn,
but that is likely overkill.
-Chris

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

[Intel-gfx] [PATCH i-g-t] tests/drv_missed_irq_hang: Fix gem_blt path

[Mika Kuoppala]

Don't add SOURCE_DIR to the path for gem_blt as if this
script is invocated on some other directory, the path to
gem_blt will be concatenated two times.

References: https://bugs.freedesktop.org/show_bug.cgi?id=88437
Cc: Chris Wilson 
Signed-off-by: Mika Kuoppala 
---
 tests/drv_missed_irq_hang | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/drv_missed_irq_hang b/tests/drv_missed_irq_hang
index e76c7db674ac..96a653846005 100755
--- a/tests/drv_missed_irq_hang
+++ b/tests/drv_missed_irq_hang
@@ -6,12 +6,12 @@
 SOURCE_DIR="$( dirname "${BASH_SOURCE[0]}" )"
 . $SOURCE_DIR/drm_lib.sh
 
-oldpath=`pwd`
+oldpath=$PWD
 
 cd $i915_dfs_path
 
 function blt_wait {
-   $oldpath/$SOURCE_DIR/../benchmarks/gem_blt -r 1 -b 64 -t 1 -S > 
/dev/null
+   ${oldpath}/../benchmarks/gem_blt -r 1 -b 64 -t 1 -S > /dev/null
 }
 
 function check_for_missed_irq {
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH v10 00/10] Introduce the implementation of GVT context

[Wang, Zhi A]

Also CC Daniel. I have got "Reviewed-by" and passed the ABAT tests. Is there 
anything I should do before patches get picked?

Thanks,
Zhi.

> -Original Message-
> From: Wang, Zhi A
> Sent: Monday, June 13, 2016 4:17 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: ch...@chris-wilson.co.uk; Lv, Zhiyuan ; Tian, Kevin
> ; tvrtko.ursu...@linux.intel.com;
> joonas.lahti...@linux.intel.com
> Subject: RE: [PATCH v10 00/10] Introduce the implementation of GVT context
> 
> Hi Chris:
> As Joonas is on vacation, can you pick my patches? or if you have some
> comments I can continue improving them.
> 
> Thanks,
> Zhi.
> 
> > -Original Message-
> > From: Wang, Zhi A
> > Sent: Thursday, June 09, 2016 9:44 PM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: ch...@chris-wilson.co.uk; Lv, Zhiyuan ;
> > Tian, Kevin ; tvrtko.ursu...@linux.intel.com;
> > joonas.lahti...@linux.intel.com; Wang, Zhi A 
> > Subject: [PATCH v10 00/10] Introduce the implementation of GVT context
> >
> > This patchset introduces the implementation of GVT context. GVT
> > context is a special GEM context used by GVT-g. GVT-g uses it as the
> > shadow context.It doesn't have a drm client nor a PPGTT. And it
> > requires a larger ring buffer with several special features need by
> > GVT-g workload scheduler like context status change notification, context
> single submission...
> >
> > ABAT results and link:
> >
> > Series: Introduce the implementation of GVT context
> > URL   : https://patchwork.freedesktop.org/series/8470/
> > State : success
> >
> > v10:
> >
> > - Take Joonas' comments.
> >
> > v9:
> >
> > - Take Chris' comments.
> >
> > v8:
> >
> > - Take Joonas/Chris's comments.
> >
> > v7:
> >
> > - Take Joonas comments.
> >
> > v6:
> >
> > - Take Chris comments.
> >
> > v5:
> >
> > - Drop PPGTT related patches.
> > - Let most functions take struct drm_i915_private *
> > - Fixed some misspelled words in Kconfig
> > - Only complied some feature when CONFIG_DRM_I915_GVT=y
> > - Drop the fecne related changes, will send it after this series.
> >
> > v4:
> >
> > - Based on the latest drm-intel-nightly branch.
> > - Drop PPGTT refactor patches. (GVT-g will use LRI to load PDPs)
> > - Drop i915_gem_context() refactor patches, reuse kernel context functions.
> >   (Dave Gordon)
> > - Drop context allocation params and refactor as the lrc deferred
> >   allocation function has been refactored in another styles.
> > - Re-wrtie GVT context creation function
> >
> > Difference from community release
> > -
> >
> > This patchset is different from regular iGVT-g code release[4], which
> > is still based on old host-mediated architecture. Furthermore, this
> > patchset only supports BDW whereas code release supports HSW/BDW/SKL.
> > We will add SKL support later based on this RFC code and HSW support
> > will be dropped.
> >
> > Internally we tested this RFC patchset with both linux and windows VM
> > and the architecture changes work fine.
> >
> > Acknowledgment
> > ---
> >
> > iGVT-g implementation is several years effort and many people
> > contributed to the code. There names are not here yet. In later formal
> > patchset we will reflect individual's contribution.
> >
> > Meanwhile, in the previous iGVT-g related discussion, Daniel, Chris
> > and Joonas ever gave very good inputs. We appreciate them and look
> > forward to more comments/suggestions from community.
> >
> > We are trying to get more familiar with i915 but may still have gaps.
> > We are willing to adopt suggestions to keep improving. We hope to work
> > with community together to make iGVT-g a great component in i915 to
> > support graphics virtualization. Thanks!
> >
> > Reference
> > -
> >
> > [1] https://01.org/igvt-g
> > [2]
> > http://lists.freedesktop.org/archives/intel-gfx/2014-September/053098.
> > html
> > [3]
> > http://lists.freedesktop.org/archives/intel-gfx/2015-September/075397.
> > html
> >
> >
> > Bing Niu (1):
> >   drm/i915: Introduce host graphics memory partition for GVT-g
> >
> > Zhi Wang (9):
> >   drm/i915: Factor out i915_pvinfo.h
> >   drm/i915: Use offsetof() to calculate the offset of members in PVINFO
> > page
> >   drm/i915: Fold vGPU active check into inner functions
> >   drm/i915: gvt: Introduce the basic architecture of GVT-g
> >   drm/i915: Make ring buffer size of a LRC context configurable
> >   drm/i915: Make addressing mode bits in context descriptor configurable
> >   drm/i915: Introduce execlist context status change notification
> >   drm/i915: Support LRC context single submission
> >   drm/i915: Introduce GVT context creation API
> >
> >  drivers/gpu/drm/i915/Kconfig|  22 +
> >  drivers/gpu/drm/i915/Makefile   |   5 ++
> >  drivers/gpu/drm/i915/gvt/Makefile   |   5 ++
> >  drivers/gpu/drm/i915/gvt/debug.h|  34 
> >  

Re: [Intel-gfx] [RESENT PATCH] drm/i915: use #defines for qemu subsystem ids

[Jani Nikula]

On Mon, 13 Jun 2016, Gerd Hoffmann  wrote:
> Signed-off-by: Gerd Hoffmann 

Reviewed-by: Jani Nikula 


> ---
>  drivers/gpu/drm/i915/i915_drv.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index f313b4d..3099390 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -515,8 +515,10 @@ void intel_detect_pch(struct drm_device *dev)
>   } else if ((id == INTEL_PCH_P2X_DEVICE_ID_TYPE) ||
>  (id == INTEL_PCH_P3X_DEVICE_ID_TYPE) ||
>  ((id == INTEL_PCH_QEMU_DEVICE_ID_TYPE) &&
> - pch->subsystem_vendor == 0x1af4 &&
> - pch->subsystem_device == 0x1100)) {
> + pch->subsystem_vendor ==
> + PCI_SUBVENDOR_ID_REDHAT_QUMRANET &&
> + pch->subsystem_device ==
> + PCI_SUBDEVICE_ID_QEMU)) {
>   dev_priv->pch_type = intel_virt_detect_pch(dev);
>   } else
>   continue;

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

Re: [Intel-gfx] [PATCH v10 00/10] Introduce the implementation of GVT context

[Wang, Zhi A]

Hi Chris:
As Joonas is on vacation, can you pick my patches? or if you have some 
comments I can continue improving them.

Thanks,
Zhi.

> -Original Message-
> From: Wang, Zhi A
> Sent: Thursday, June 09, 2016 9:44 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: ch...@chris-wilson.co.uk; Lv, Zhiyuan ; Tian, Kevin
> ; tvrtko.ursu...@linux.intel.com;
> joonas.lahti...@linux.intel.com; Wang, Zhi A 
> Subject: [PATCH v10 00/10] Introduce the implementation of GVT context
> 
> This patchset introduces the implementation of GVT context. GVT context is a
> special GEM context used by GVT-g. GVT-g uses it as the shadow context.It
> doesn't have a drm client nor a PPGTT. And it requires a larger ring buffer 
> with
> several special features need by GVT-g workload scheduler like context status
> change notification, context single submission...
> 
> ABAT results and link:
> 
> Series: Introduce the implementation of GVT context
> URL   : https://patchwork.freedesktop.org/series/8470/
> State : success
> 
> v10:
> 
> - Take Joonas' comments.
> 
> v9:
> 
> - Take Chris' comments.
> 
> v8:
> 
> - Take Joonas/Chris's comments.
> 
> v7:
> 
> - Take Joonas comments.
> 
> v6:
> 
> - Take Chris comments.
> 
> v5:
> 
> - Drop PPGTT related patches.
> - Let most functions take struct drm_i915_private *
> - Fixed some misspelled words in Kconfig
> - Only complied some feature when CONFIG_DRM_I915_GVT=y
> - Drop the fecne related changes, will send it after this series.
> 
> v4:
> 
> - Based on the latest drm-intel-nightly branch.
> - Drop PPGTT refactor patches. (GVT-g will use LRI to load PDPs)
> - Drop i915_gem_context() refactor patches, reuse kernel context functions.
>   (Dave Gordon)
> - Drop context allocation params and refactor as the lrc deferred
>   allocation function has been refactored in another styles.
> - Re-wrtie GVT context creation function
> 
> Difference from community release
> -
> 
> This patchset is different from regular iGVT-g code release[4], which is still
> based on old host-mediated architecture. Furthermore, this patchset only
> supports BDW whereas code release supports HSW/BDW/SKL.
> We will add SKL support later based on this RFC code and HSW support will be
> dropped.
> 
> Internally we tested this RFC patchset with both linux and windows VM and the
> architecture changes work fine.
> 
> Acknowledgment
> ---
> 
> iGVT-g implementation is several years effort and many people contributed to
> the code. There names are not here yet. In later formal patchset we will 
> reflect
> individual's contribution.
> 
> Meanwhile, in the previous iGVT-g related discussion, Daniel, Chris and Joonas
> ever gave very good inputs. We appreciate them and look forward to more
> comments/suggestions from community.
> 
> We are trying to get more familiar with i915 but may still have gaps.
> We are willing to adopt suggestions to keep improving. We hope to work with
> community together to make iGVT-g a great component in i915 to support
> graphics virtualization. Thanks!
> 
> Reference
> -
> 
> [1] https://01.org/igvt-g
> [2]
> http://lists.freedesktop.org/archives/intel-gfx/2014-September/053098.html
> [3]
> http://lists.freedesktop.org/archives/intel-gfx/2015-September/075397.html
> 
> 
> Bing Niu (1):
>   drm/i915: Introduce host graphics memory partition for GVT-g
> 
> Zhi Wang (9):
>   drm/i915: Factor out i915_pvinfo.h
>   drm/i915: Use offsetof() to calculate the offset of members in PVINFO
> page
>   drm/i915: Fold vGPU active check into inner functions
>   drm/i915: gvt: Introduce the basic architecture of GVT-g
>   drm/i915: Make ring buffer size of a LRC context configurable
>   drm/i915: Make addressing mode bits in context descriptor configurable
>   drm/i915: Introduce execlist context status change notification
>   drm/i915: Support LRC context single submission
>   drm/i915: Introduce GVT context creation API
> 
>  drivers/gpu/drm/i915/Kconfig|  22 +
>  drivers/gpu/drm/i915/Makefile   |   5 ++
>  drivers/gpu/drm/i915/gvt/Makefile   |   5 ++
>  drivers/gpu/drm/i915/gvt/debug.h|  34 
>  drivers/gpu/drm/i915/gvt/gvt.c  | 145
> 
>  drivers/gpu/drm/i915/gvt/gvt.h  |  69 +++
>  drivers/gpu/drm/i915/gvt/hypercall.h|  38 +
>  drivers/gpu/drm/i915/gvt/mpt.h  |  49 +++
>  drivers/gpu/drm/i915/i915_dma.c |  16 +++-
>  drivers/gpu/drm/i915/i915_drv.h |  16 
>  drivers/gpu/drm/i915/i915_gem_context.c |  38 +
>  drivers/gpu/drm/i915/i915_gem_gtt.c |  11 +--
>  drivers/gpu/drm/i915/i915_params.c  |   5 ++
>  drivers/gpu/drm/i915/i915_params.h  |   1 +
>  drivers/gpu/drm/i915/i915_pvinfo.h  | 113
> +
>  drivers/gpu/drm/i915/i915_reg.h |  12 +++
>  

Re: [Intel-gfx] [PATCH 6/7] drm/i915: Remove mostly duplicated video DIP handling from PSR code

[Sharma, Shashank]

Regards
Shashank

On 6/13/2016 5:57 PM, Ville Syrjälä wrote:

On Mon, Jun 13, 2016 at 05:39:47PM +0530, Sharma, Shashank wrote:

Regards
Shashank

On 6/3/2016 1:25 AM, ville.syrj...@linux.intel.com wrote:

From: Ville Syrjälä 

Now that the infoframe hooks are part of the intel_dig_port, we can use
the normal .write_infoframe() hook to update the VSC SDP. We do need to
deal with the size difference between the VSC DIP and the others though.

Another minor snag is that the compiler will complain to use if we keep
using enum hdmi_infoframe_type type and passing in the DP define instead,
so et's just change to unsigned int all over for the inforframe type.

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

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 4c8451e3d8f1..5dcaa14ff90d 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -900,7 +900,7 @@ struct intel_digital_port {
/* for communication with audio component; protected by av_mutex */
const struct drm_connector *audio_connector;
void (*write_infoframe)(struct drm_encoder *encoder,
-   enum hdmi_infoframe_type type,
+   unsigned int type,
const void *frame, ssize_t len);
void (*set_infoframes)(struct drm_encoder *encoder,
   bool enable,
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 637b17baf798..600a58210450 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -68,7 +68,7 @@ static struct intel_hdmi *intel_attached_hdmi(struct 
drm_connector *connector)
return enc_to_intel_hdmi(_attached_encoder(connector)->base);
   }

-static u32 g4x_infoframe_index(enum hdmi_infoframe_type type)
+static u32 g4x_infoframe_index(unsigned int type)
   {
switch (type) {
case HDMI_INFOFRAME_TYPE_AVI:
@@ -83,7 +83,7 @@ static u32 g4x_infoframe_index(enum hdmi_infoframe_type type)
}
   }

-static u32 g4x_infoframe_enable(enum hdmi_infoframe_type type)
+static u32 g4x_infoframe_enable(unsigned int type)
   {
switch (type) {
case HDMI_INFOFRAME_TYPE_AVI:
@@ -98,9 +98,11 @@ static u32 g4x_infoframe_enable(enum hdmi_infoframe_type 
type)
}
   }

-static u32 hsw_infoframe_enable(enum hdmi_infoframe_type type)
+static u32 hsw_infoframe_enable(unsigned int type)
   {
switch (type) {
+   case DP_SDP_VSC:

Why do we need a new field like this ? Would it make sense to set the
type itself as "HDMI_INFOFRAME_TYPE_AVI" ?


We want to enable/write the VSC, not the AVI.

Ok, This patch generally looks good, but I am not sure I am the right 
guy to check this patch further, so I will pass it from here. We might 
need another opinion on this.

+   return VIDEO_DIP_ENABLE_VSC_HSW;
case HDMI_INFOFRAME_TYPE_AVI:
return VIDEO_DIP_ENABLE_AVI_HSW;
case HDMI_INFOFRAME_TYPE_SPD:
@@ -116,10 +118,12 @@ static u32 hsw_infoframe_enable(enum hdmi_infoframe_type 
type)
   static i915_reg_t
   hsw_dip_data_reg(struct drm_i915_private *dev_priv,
 enum transcoder cpu_transcoder,
-enum hdmi_infoframe_type type,
+unsigned int type,
 int i)
   {
switch (type) {
+   case DP_SDP_VSC:
+   return HSW_TVIDEO_DIP_VSC_DATA(cpu_transcoder, i);
case HDMI_INFOFRAME_TYPE_AVI:
return HSW_TVIDEO_DIP_AVI_DATA(cpu_transcoder, i);
case HDMI_INFOFRAME_TYPE_SPD:
@@ -133,7 +137,7 @@ hsw_dip_data_reg(struct drm_i915_private *dev_priv,
   }

   static void g4x_write_infoframe(struct drm_encoder *encoder,
-   enum hdmi_infoframe_type type,
+   unsigned int type,
const void *frame, ssize_t len)
   {
const uint32_t *data = frame;
@@ -187,7 +191,7 @@ static bool g4x_infoframe_enabled(struct drm_encoder 
*encoder,
   }

   static void ibx_write_infoframe(struct drm_encoder *encoder,
-   enum hdmi_infoframe_type type,
+   unsigned int type,
const void *frame, ssize_t len)
   {
const uint32_t *data = frame;
@@ -246,7 +250,7 @@ static bool ibx_infoframe_enabled(struct drm_encoder 
*encoder,
   }

   static void cpt_write_infoframe(struct drm_encoder *encoder,
-   enum hdmi_infoframe_type type,
+   unsigned int type,
const void *frame, ssize_t 

Re: [Intel-gfx] [PATCH] drm/i915: pwrite/pread do not require obj->base.filp, just pages

[Tvrtko Ursulin]

On 13/06/16 13:52, Chris Wilson wrote:

On Mon, Jun 13, 2016 at 01:45:56PM +0100, Tvrtko Ursulin wrote:


On 13/06/16 13:40, Chris Wilson wrote:

The idea behind relaxing the restriction for pread/pwrite was to handle
!obj->base.flip, i.e. non-shmemfs backed objects, which only requires
that the object provide struct pages.

v2: Remove excess (). Note enough editing after copy'n'paste.

Signed-off-by: Chris Wilson 
Cc: Ankitprasad Sharma 
Cc: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/i915_gem.c | 7 ---
  1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 21d0dea57312..6f950c37efab 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -760,7 +760,7 @@ i915_gem_shmem_pread(struct drm_device *dev,
int needs_clflush = 0;
struct sg_page_iter sg_iter;

-   if (!obj->base.filp)
+   if ((obj->ops->flags & I915_GEM_OBJECT_HAS_STRUCT_PAGE) == 0)
return -ENODEV;

user_data = u64_to_user_ptr(args->data_ptr);
@@ -1298,7 +1298,8 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void *data,
 * pread/pwrite currently are reading and writing from the CPU
 * perspective, requiring manual detiling by the client.
 */
-   if (!obj->base.filp || cpu_write_needs_clflush(obj)) {
+   if ((obj->ops->flags & I915_GEM_OBJECT_HAS_STRUCT_PAGE) == 0 ||
+   cpu_write_needs_clflush(obj)) {
ret = i915_gem_gtt_pwrite_fast(dev_priv, obj, args, file);
/* Note that the gtt paths might fail with non-page-backed user
 * pointers (e.g. gtt mappings when moving data between
@@ -1308,7 +1309,7 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void *data,
if (ret == -EFAULT) {
if (obj->phys_handle)
ret = i915_gem_phys_pwrite(obj, args, file);
-   else if (obj->base.filp)
+   else if (obj->ops->flags & I915_GEM_OBJECT_HAS_STRUCT_PAGE)
ret = i915_gem_shmem_pwrite(dev, obj, args, file);
else
ret = -ENODEV;



To enable on userptr or there is more to it? Would it even make more
sense to keep rejecting it on userptr to discourage suboptimal
userspace?


And prime objects, and everything in future not backed by a filp.


Hmm.. I sense a hole in the IGT coverage. :)

You definitely do not mind allowing it with userptr?

Actually, we don't need to go through the aperture for anything but 
stolen, right? A third, more optimal path could be added for page backed 
objects which are not shmem, not userptr and not stolen.


Regards,

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

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with drm/i915: pwrite/pread do not require obj->base.filp, just pages (rev3)

[Patchwork]

== Series Details ==

Series: series starting with drm/i915: pwrite/pread do not require 
obj->base.filp, just pages (rev3)
URL   : https://patchwork.freedesktop.org/series/8528/
State : failure

== Summary ==

Applying: drm/i915: pwrite/pread do not require obj->base.filp, just pages
Applying: drm/i915: Introduce i915_gem_object_get_dma_address()
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/i915_drv.h
Falling back to patching base and 3-way merge...
No changes -- Patch already applied.
Applying: drm/i915: Use insert_page for pwrite_fast
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/i915_gem.c
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/i915_gem.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/i915_gem.c
error: Failed to merge in the changes.
Patch failed at 0003 drm/i915: Use insert_page for pwrite_fast
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

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

[Intel-gfx] ✗ Ro.CI.BAT: warning for drm/i915: use #defines for qemu subsystem ids (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: use #defines for qemu subsystem ids (rev2)
URL   : https://patchwork.freedesktop.org/series/2918/
State : warning

== Summary ==

Series 2918v2 drm/i915: use #defines for qemu subsystem ids
http://patchwork.freedesktop.org/api/1.0/series/2918/revisions/2/mbox

Test kms_force_connector_basic:
Subgroup force-connector-state:
skip   -> PASS   (ro-ivb2-i7-3770)
Subgroup force-edid:
skip   -> PASS   (ro-ivb2-i7-3770)
Subgroup prune-stale-modes:
skip   -> PASS   (ro-ivb2-i7-3770)
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-b-frame-sequence:
pass   -> SKIP   (fi-skl-i5-6260u)
Subgroup suspend-read-crc-pipe-b:
skip   -> DMESG-WARN (ro-bdw-i5-5250u)
Subgroup suspend-read-crc-pipe-c:
dmesg-warn -> SKIP   (ro-bdw-i5-5250u)

fi-bdw-i7-5557u  total:213  pass:201  dwarn:0   dfail:0   fail:0   skip:12 
fi-skl-i5-6260u  total:213  pass:201  dwarn:0   dfail:0   fail:0   skip:12 
fi-skl-i7-6700k  total:213  pass:188  dwarn:0   dfail:0   fail:0   skip:25 
fi-snb-i7-2600   total:213  pass:174  dwarn:0   dfail:0   fail:0   skip:39 
ro-bdw-i5-5250u  total:213  pass:197  dwarn:2   dfail:0   fail:0   skip:14 
ro-bdw-i7-5557U  total:213  pass:198  dwarn:0   dfail:0   fail:0   skip:15 
ro-bdw-i7-5600u  total:213  pass:185  dwarn:0   dfail:0   fail:0   skip:28 
ro-bsw-n3050 total:213  pass:172  dwarn:0   dfail:0   fail:2   skip:39 
ro-byt-n2820 total:213  pass:173  dwarn:0   dfail:0   fail:3   skip:37 
ro-hsw-i3-4010u  total:213  pass:190  dwarn:0   dfail:0   fail:0   skip:23 
ro-hsw-i7-4770r  total:213  pass:190  dwarn:0   dfail:0   fail:0   skip:23 
ro-ilk-i7-620lm  total:177  pass:120  dwarn:2   dfail:2   fail:1   skip:51 
ro-ilk1-i5-650   total:208  pass:150  dwarn:0   dfail:0   fail:1   skip:57 
ro-ivb-i7-3770   total:213  pass:181  dwarn:0   dfail:0   fail:0   skip:32 
ro-ivb2-i7-3770  total:213  pass:185  dwarn:0   dfail:0   fail:0   skip:28 
ro-skl3-i5-6260u total:213  pass:201  dwarn:1   dfail:0   fail:0   skip:11 
ro-snb-i7-2620M  total:213  pass:174  dwarn:0   dfail:0   fail:1   skip:38 
fi-hsw-i7-4770k failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1174/

f80cfb4 drm-intel-nightly: 2016y-06m-13d-10h-41m-19s UTC integration manifest
ddb6763 drm/i915: use #defines for qemu subsystem ids

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

Re: [Intel-gfx] [PATCH 4/7] drm/i915: Move infoframe vfuncs into intel_digital_port

[Sharma, Shashank]

Reviewed-by: Shashank Sharma

Regards
Shashank
On 6/13/2016 5:55 PM, Ville Syrjälä wrote:

On Mon, Jun 13, 2016 at 03:47:13PM +0530, Sharma, Shashank wrote:

Regards
Shashank

On 6/3/2016 1:25 AM, ville.syrj...@linux.intel.com wrote:

From: Ville Syrjälä 

DP ports will also want to utilize the video DIP for SDP transmission.
So let's move the vfuncs into the dig_port.

Signed-off-by: Ville Syrjälä 
---
   drivers/gpu/drm/i915/intel_ddi.c  | 20 ++--
   drivers/gpu/drm/i915/intel_drv.h  | 16 +-
   drivers/gpu/drm/i915/intel_hdmi.c | 64 
---
   3 files changed, 52 insertions(+), 48 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 6ff2a7b97ca6..3a882a979e5d 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1628,11 +1628,12 @@ static void intel_ddi_pre_enable(struct intel_encoder 
*intel_encoder)
if (port != PORT_A || INTEL_INFO(dev_priv)->gen >= 9)
intel_dp_stop_link_train(intel_dp);
} else if (type == INTEL_OUTPUT_HDMI) {
-   struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
+   struct intel_digital_port *intel_dig_port =
+   enc_to_dig_port(encoder);

-   intel_hdmi->set_infoframes(encoder,
-  crtc->config->has_infoframe,
-  >config->base.adjusted_mode);
+   intel_dig_port->set_infoframes(encoder,
+  crtc->config->has_infoframe,
+

We have kept this call still inside if (type == HDMI); now when the aim
is to make it common for all DDI interfaces, do we need this check ?
   
>config->base.adjusted_mode);


This is a purely mechanical change. No change in behaviour.


}
   }

@@ -1662,9 +1663,10 @@ static void intel_ddi_post_disable(struct intel_encoder 
*intel_encoder)
intel_wait_ddi_buf_idle(dev_priv, port);

if (type == INTEL_OUTPUT_HDMI) {
-   struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
+   struct intel_digital_port *intel_dig_port =
+   enc_to_dig_port(encoder);

-   intel_hdmi->set_infoframes(encoder, false, NULL);
+   intel_dig_port->set_infoframes(encoder, false, NULL);

Same as above.

}

if (type == INTEL_OUTPUT_DISPLAYPORT || type == INTEL_OUTPUT_EDP) {
@@ -2155,7 +2157,7 @@ void intel_ddi_get_config(struct intel_encoder *encoder,
struct drm_i915_private *dev_priv = encoder->base.dev->dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
enum transcoder cpu_transcoder = pipe_config->cpu_transcoder;
-   struct intel_hdmi *intel_hdmi;
+   struct intel_digital_port *intel_dig_port;
u32 temp, flags = 0;

/* XXX: DSI transcoder paranoia */
@@ -2194,9 +2196,9 @@ void intel_ddi_get_config(struct intel_encoder *encoder,
switch (temp & TRANS_DDI_MODE_SELECT_MASK) {
case TRANS_DDI_MODE_SELECT_HDMI:

case TRANS_DDI_MODE_SELECT_DP here: ?

pipe_config->has_hdmi_sink = true;
-   intel_hdmi = enc_to_intel_hdmi(>base);
+   intel_dig_port = enc_to_dig_port(>base);

-   if (intel_hdmi->infoframe_enabled(>base, pipe_config))
+   if (intel_dig_port->infoframe_enabled(>base, 
pipe_config))
pipe_config->has_infoframe = true;
/* fall through */
case TRANS_DDI_MODE_SELECT_DVI:
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index ebe7b3427e2e..a607799b7776 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -790,14 +790,6 @@ struct intel_hdmi {
bool rgb_quant_range_selectable;
enum hdmi_picture_aspect aspect_ratio;
struct intel_connector *attached_connector;
-   void (*write_infoframe)(struct drm_encoder *encoder,
-   enum hdmi_infoframe_type type,
-   const void *frame, ssize_t len);
-   void (*set_infoframes)(struct drm_encoder *encoder,
-  bool enable,
-  const struct drm_display_mode *adjusted_mode);
-   bool (*infoframe_enabled)(struct drm_encoder *encoder,
- const struct intel_crtc_state *pipe_config);
   };

   struct intel_dp_mst_encoder;
@@ -907,6 +899,14 @@ struct intel_digital_port {
uint8_t max_lanes;
/* for communication with audio component; protected by av_mutex */
const struct drm_connector *audio_connector;
+   void (*write_infoframe)(struct drm_encoder *encoder,
+   enum 

Re: [Intel-gfx] [PATCH] drm/i915: pwrite/pread do not require obj->base.filp, just pages

[Chris Wilson]

On Mon, Jun 13, 2016 at 01:45:56PM +0100, Tvrtko Ursulin wrote:
> 
> On 13/06/16 13:40, Chris Wilson wrote:
> >The idea behind relaxing the restriction for pread/pwrite was to handle
> >!obj->base.flip, i.e. non-shmemfs backed objects, which only requires
> >that the object provide struct pages.
> >
> >v2: Remove excess (). Note enough editing after copy'n'paste.
> >
> >Signed-off-by: Chris Wilson 
> >Cc: Ankitprasad Sharma 
> >Cc: Tvrtko Ursulin 
> >---
> >  drivers/gpu/drm/i915/i915_gem.c | 7 ---
> >  1 file changed, 4 insertions(+), 3 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> >b/drivers/gpu/drm/i915/i915_gem.c
> >index 21d0dea57312..6f950c37efab 100644
> >--- a/drivers/gpu/drm/i915/i915_gem.c
> >+++ b/drivers/gpu/drm/i915/i915_gem.c
> >@@ -760,7 +760,7 @@ i915_gem_shmem_pread(struct drm_device *dev,
> > int needs_clflush = 0;
> > struct sg_page_iter sg_iter;
> >
> >-if (!obj->base.filp)
> >+if ((obj->ops->flags & I915_GEM_OBJECT_HAS_STRUCT_PAGE) == 0)
> > return -ENODEV;
> >
> > user_data = u64_to_user_ptr(args->data_ptr);
> >@@ -1298,7 +1298,8 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void 
> >*data,
> >  * pread/pwrite currently are reading and writing from the CPU
> >  * perspective, requiring manual detiling by the client.
> >  */
> >-if (!obj->base.filp || cpu_write_needs_clflush(obj)) {
> >+if ((obj->ops->flags & I915_GEM_OBJECT_HAS_STRUCT_PAGE) == 0 ||
> >+cpu_write_needs_clflush(obj)) {
> > ret = i915_gem_gtt_pwrite_fast(dev_priv, obj, args, file);
> > /* Note that the gtt paths might fail with non-page-backed user
> >  * pointers (e.g. gtt mappings when moving data between
> >@@ -1308,7 +1309,7 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void 
> >*data,
> > if (ret == -EFAULT) {
> > if (obj->phys_handle)
> > ret = i915_gem_phys_pwrite(obj, args, file);
> >-else if (obj->base.filp)
> >+else if (obj->ops->flags & I915_GEM_OBJECT_HAS_STRUCT_PAGE)
> > ret = i915_gem_shmem_pwrite(dev, obj, args, file);
> > else
> > ret = -ENODEV;
> >
> 
> To enable on userptr or there is more to it? Would it even make more
> sense to keep rejecting it on userptr to discourage suboptimal
> userspace?

And prime objects, and everything in future not backed by a filp.
-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 3/7] drm/i915: Disable infoframes when shutting down DDI HDMI

[Sharma, Shashank]

Ok, apart from this, looks good to me.
Reviewed-by: Shashank Sharma

Regards
Shashank

On 6/13/2016 5:54 PM, Ville Syrjälä wrote:

On Mon, Jun 13, 2016 at 03:36:19PM +0530, Sharma, Shashank wrote:

Regards
Shashank

On 6/3/2016 1:25 AM, ville.syrj...@linux.intel.com wrote:

From: Ville Syrjälä 

Disabling the video DIP when shutting the port down seems like a good
idea.

Bspec says:
"When disabling both the DIP port and DIP transmission,
   first disable the port and then disable DIP."
and
"Restriction : GCP is only supported with HDMI when the bits per color is
   not equal to 8. GCP must be enabled prior to enabling TRANS_DDI_FUNC_CTL
   for HDMI with bits per color not equal to 8 and disabled after disabling
   TRANS_DDI_FUNC_CTL"

So let's do it in the .post_disable() hook.

Signed-off-by: Ville Syrjälä 
---
   drivers/gpu/drm/i915/intel_ddi.c | 6 ++
   1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 2fb28d310c22..6ff2a7b97ca6 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1661,6 +1661,12 @@ static void intel_ddi_post_disable(struct intel_encoder 
*intel_encoder)
if (wait)
intel_wait_ddi_buf_idle(dev_priv, port);

+   if (type == INTEL_OUTPUT_HDMI) {
+   struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
+
+   intel_hdmi->set_infoframes(encoder, false, NULL);

I have seen an assert_hdmi_port_disabled in hsw_set_infoframes, it will
cause assert.


No. We've already turned off the port by this time.


+   }
+
if (type == INTEL_OUTPUT_DISPLAYPORT || type == INTEL_OUTPUT_EDP) {
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);




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

Re: [Intel-gfx] [PATCH 2/7] drm/i915: Check has_infoframes when enabling infoframes

[Sharma, Shashank]

Regards
Shashank

On 6/13/2016 5:54 PM, Ville Syrjälä wrote:

On Mon, Jun 13, 2016 at 01:40:50PM +0530, Sharma, Shashank wrote:

Regards
Shashank

On 6/3/2016 1:25 AM, ville.syrj...@linux.intel.com wrote:

From: Ville Syrjälä 

has_infoframe is what tells us whether infoframes should be enabled, so
let's pass that instead of has_hdmi_sink to .set_infoframes().

Signed-off-by: Ville Syrjälä 
---
   drivers/gpu/drm/i915/intel_ddi.c  | 2 +-
   drivers/gpu/drm/i915/intel_hdmi.c | 6 +++---
   2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 022b41d422dc..2fb28d310c22 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1631,7 +1631,7 @@ static void intel_ddi_pre_enable(struct intel_encoder 
*intel_encoder)
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);

intel_hdmi->set_infoframes(encoder,
-  crtc->config->has_hdmi_sink,
+  crtc->config->has_infoframe,

I am a bit confused here, please correct me if I am not going in right
direction, but what if its a DVI device which still needs video/AVI
infoframes but can drop Audio IF ? Wont it make more sense to keep using
has_hdmi_sink ?


DVI doesn't do infoframes, so not sure what you're asking here. Also we
don't deal with audio infoframes here.

Sorry, I guess I was under the (wrong) assumption that DVI still needs 
information(like aspect ratio) in form of infoframes, only the audio 
info frames are skipped.

   >config->base.adjusted_mode);
}
   }
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index eb455ea6ea92..067b10a7cb04 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1665,7 +1665,7 @@ static void intel_hdmi_pre_enable(struct intel_encoder 
*encoder)
intel_hdmi_prepare(encoder);

intel_hdmi->set_infoframes(>base,
-  intel_crtc->config->has_hdmi_sink,
+  intel_crtc->config->has_infoframe,

Same as above

Regards
Shashank

   adjusted_mode);
   }

@@ -1686,7 +1686,7 @@ static void vlv_hdmi_pre_enable(struct intel_encoder 
*encoder)
 0x2b247878);

intel_hdmi->set_infoframes(>base,
-  intel_crtc->config->has_hdmi_sink,
+  intel_crtc->config->has_infoframe,
   adjusted_mode);

g4x_enable_hdmi(encoder);
@@ -1749,7 +1749,7 @@ static void chv_hdmi_pre_enable(struct intel_encoder 
*encoder)
chv_set_phy_signal_level(encoder, 128, 102, false);

intel_hdmi->set_infoframes(>base,
-  intel_crtc->config->has_hdmi_sink,
+  intel_crtc->config->has_infoframe,
   adjusted_mode);

g4x_enable_hdmi(encoder);




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

Re: [Intel-gfx] [PATCH] drm/i915: pwrite/pread do not require obj->base.filp, just pages

[Tvrtko Ursulin]

On 13/06/16 13:40, Chris Wilson wrote:

The idea behind relaxing the restriction for pread/pwrite was to handle
!obj->base.flip, i.e. non-shmemfs backed objects, which only requires
that the object provide struct pages.

v2: Remove excess (). Note enough editing after copy'n'paste.

Signed-off-by: Chris Wilson 
Cc: Ankitprasad Sharma 
Cc: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/i915_gem.c | 7 ---
  1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 21d0dea57312..6f950c37efab 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -760,7 +760,7 @@ i915_gem_shmem_pread(struct drm_device *dev,
int needs_clflush = 0;
struct sg_page_iter sg_iter;

-   if (!obj->base.filp)
+   if ((obj->ops->flags & I915_GEM_OBJECT_HAS_STRUCT_PAGE) == 0)
return -ENODEV;

user_data = u64_to_user_ptr(args->data_ptr);
@@ -1298,7 +1298,8 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void *data,
 * pread/pwrite currently are reading and writing from the CPU
 * perspective, requiring manual detiling by the client.
 */
-   if (!obj->base.filp || cpu_write_needs_clflush(obj)) {
+   if ((obj->ops->flags & I915_GEM_OBJECT_HAS_STRUCT_PAGE) == 0 ||
+   cpu_write_needs_clflush(obj)) {
ret = i915_gem_gtt_pwrite_fast(dev_priv, obj, args, file);
/* Note that the gtt paths might fail with non-page-backed user
 * pointers (e.g. gtt mappings when moving data between
@@ -1308,7 +1309,7 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void *data,
if (ret == -EFAULT) {
if (obj->phys_handle)
ret = i915_gem_phys_pwrite(obj, args, file);
-   else if (obj->base.filp)
+   else if (obj->ops->flags & I915_GEM_OBJECT_HAS_STRUCT_PAGE)
ret = i915_gem_shmem_pwrite(dev, obj, args, file);
else
ret = -ENODEV;



To enable on userptr or there is more to it? Would it even make more 
sense to keep rejecting it on userptr to discourage suboptimal userspace?


Regards,

Tvrtko

P.S. You need to send it outside this thread to get a CI run.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: pwrite/pread do not require obj->base.filp, just pages

[Chris Wilson]

The idea behind relaxing the restriction for pread/pwrite was to handle
!obj->base.flip, i.e. non-shmemfs backed objects, which only requires
that the object provide struct pages.

v2: Remove excess (). Note enough editing after copy'n'paste.

Signed-off-by: Chris Wilson 
Cc: Ankitprasad Sharma 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 21d0dea57312..6f950c37efab 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -760,7 +760,7 @@ i915_gem_shmem_pread(struct drm_device *dev,
int needs_clflush = 0;
struct sg_page_iter sg_iter;
 
-   if (!obj->base.filp)
+   if ((obj->ops->flags & I915_GEM_OBJECT_HAS_STRUCT_PAGE) == 0)
return -ENODEV;
 
user_data = u64_to_user_ptr(args->data_ptr);
@@ -1298,7 +1298,8 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void *data,
 * pread/pwrite currently are reading and writing from the CPU
 * perspective, requiring manual detiling by the client.
 */
-   if (!obj->base.filp || cpu_write_needs_clflush(obj)) {
+   if ((obj->ops->flags & I915_GEM_OBJECT_HAS_STRUCT_PAGE) == 0 ||
+   cpu_write_needs_clflush(obj)) {
ret = i915_gem_gtt_pwrite_fast(dev_priv, obj, args, file);
/* Note that the gtt paths might fail with non-page-backed user
 * pointers (e.g. gtt mappings when moving data between
@@ -1308,7 +1309,7 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void *data,
if (ret == -EFAULT) {
if (obj->phys_handle)
ret = i915_gem_phys_pwrite(obj, args, file);
-   else if (obj->base.filp)
+   else if (obj->ops->flags & I915_GEM_OBJECT_HAS_STRUCT_PAGE)
ret = i915_gem_shmem_pwrite(dev, obj, args, file);
else
ret = -ENODEV;
-- 
2.8.1

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

[Intel-gfx] [RESENT PATCH] drm/i915: use #defines for qemu subsystem ids

[Gerd Hoffmann]

Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/i915/i915_drv.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index f313b4d..3099390 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -515,8 +515,10 @@ void intel_detect_pch(struct drm_device *dev)
} else if ((id == INTEL_PCH_P2X_DEVICE_ID_TYPE) ||
   (id == INTEL_PCH_P3X_DEVICE_ID_TYPE) ||
   ((id == INTEL_PCH_QEMU_DEVICE_ID_TYPE) &&
-   pch->subsystem_vendor == 0x1af4 &&
-   pch->subsystem_device == 0x1100)) {
+   pch->subsystem_vendor ==
+   PCI_SUBVENDOR_ID_REDHAT_QUMRANET &&
+   pch->subsystem_device ==
+   PCI_SUBDEVICE_ID_QEMU)) {
dev_priv->pch_type = intel_virt_detect_pch(dev);
} else
continue;
-- 
1.8.3.1

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

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with drm/i915: pwrite/pread do not require obj->base.filp, just pages (rev2)

[Patchwork]

== Series Details ==

Series: series starting with drm/i915: pwrite/pread do not require 
obj->base.filp, just pages (rev2)
URL   : https://patchwork.freedesktop.org/series/8528/
State : failure

== Summary ==

Applying: drm/i915: pwrite/pread do not require obj->base.filp, just pages
Applying: drm/i915: Introduce i915_gem_object_get_dma_address()
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/i915_drv.h
Falling back to patching base and 3-way merge...
No changes -- Patch already applied.
Applying: drm/i915: Use insert_page for pwrite_fast
Using index info to reconstruct a base tree...
M   drivers/gpu/drm/i915/i915_gem.c
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/i915_gem.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/i915_gem.c
error: Failed to merge in the changes.
Patch failed at 0003 drm/i915: Use insert_page for pwrite_fast
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

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

[Intel-gfx] [PATCH] drm/i915: pwrite/pread do not require obj->base.filp, just pages

[Chris Wilson]

The idea behind relaxing the restriction for pread/pwrite was to handle
!obj->base.flip, i.e. non-shmemfs backed objects, which only requires
that the object provide struct pages.

Signed-off-by: Chris Wilson 
Cc: Ankitprasad Sharma 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 21d0dea57312..0a29c57dae59 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -760,7 +760,7 @@ i915_gem_shmem_pread(struct drm_device *dev,
int needs_clflush = 0;
struct sg_page_iter sg_iter;
 
-   if (!obj->base.filp)
+   if (((obj->ops->flags & I915_GEM_OBJECT_HAS_STRUCT_PAGE) == 0))
return -ENODEV;
 
user_data = u64_to_user_ptr(args->data_ptr);
@@ -1298,7 +1298,8 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void *data,
 * pread/pwrite currently are reading and writing from the CPU
 * perspective, requiring manual detiling by the client.
 */
-   if (!obj->base.filp || cpu_write_needs_clflush(obj)) {
+   if (((obj->ops->flags & I915_GEM_OBJECT_HAS_STRUCT_PAGE) == 0) ||
+   cpu_write_needs_clflush(obj)) {
ret = i915_gem_gtt_pwrite_fast(dev_priv, obj, args, file);
/* Note that the gtt paths might fail with non-page-backed user
 * pointers (e.g. gtt mappings when moving data between
@@ -1308,7 +1309,7 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void *data,
if (ret == -EFAULT) {
if (obj->phys_handle)
ret = i915_gem_phys_pwrite(obj, args, file);
-   else if (obj->base.filp)
+   else if ((obj->ops->flags & I915_GEM_OBJECT_HAS_STRUCT_PAGE))
ret = i915_gem_shmem_pwrite(dev, obj, args, file);
else
ret = -ENODEV;
-- 
2.8.1

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

Re: [Intel-gfx] [drm:intel_set_cpu_fifo_underrun_reporting]

[Petko Manolov]

On 16-06-13 13:29:46, Petko Manolov wrote:
>   Hello guys,
> 
> Running xorg on my Lenovo Yoga 2 Pro (MY2013) on recent kernels turn into a 
> major PITA.  After a couple of minutes the screen starts to flicker and only 
> killing xorg or reboot fixes the problem.  This is what i typically see in 
> dmesg:
> 
> 
> [0.00] microcode: microcode updated early to revision 0x1d, date = 
> 2015-08-13
> [0.00] Linux version 4.7.0-rc3 (petkan@yoga) (gcc version 6.1.1 
> 20160519 (Debian 6.1.1-4) ) #5 SMP Mon Jun 13 12:41:31 EEST 2016
> [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.7.0-rc3 
> root=/dev/sda1 ro quiet
> ...
> [0.104213] smpboot: CPU0: Intel(R) Core(TM) i7-4500U CPU @ 1.80GHz 
> (family: 0x6, model: 0x45, stepping: 0x1)
> ...
> [1.033691] [drm] Initialized drm 1.1.0 20060810
> [1.034106] [drm] Memory usable by graphics device = 2048M
> [1.034108] [drm] Replacing VGA console driver
> [1.040787] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [1.040788] [drm] Driver supports precise vblank timestamp query.
> [1.066820] [drm] Initialized i915 1.6.0 20160425 for :00:02.0 on 
> minor 0
> [1.231007] fbcon: inteldrmfb (fb0) is primary device
> [2.524538] i915 :00:02.0: fb0: inteldrmfb frame buffer device
> ...
> [   92.825302] [drm:intel_set_cpu_fifo_underrun_reporting] *ERROR* uncleared 
> fifo underrun on pipe A
> [   92.825312] [drm:ironlake_irq_handler] *ERROR* CPU pipe A FIFO underrun
> 
> 
> This is going on for all v4.6 kernel releases as well as v4.7-rcX.  Older, 
> v4.4 and v4.5, kernels are running fine.  I'm using Debian testing updated to 
> 2016-06-13.
> 
> I'd be happy to help with testing so please let me know if there's anything i 
> can do for you.

It seems that James (Bottomley) has similar problem and it was suggested to him 
to try drm-intel-nightly.  Which i did, but it didn't help much.  Admittedly, 
the flicker issue showed up after about an hour instead of a couple of minutes.

The 'dmesg' output seems very much like what i posted above.


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

Re: [Intel-gfx] [PATCH 6/7] drm/i915: Remove mostly duplicated video DIP handling from PSR code

[Ville Syrjälä]

On Mon, Jun 13, 2016 at 05:39:47PM +0530, Sharma, Shashank wrote:
> Regards
> Shashank
> 
> On 6/3/2016 1:25 AM, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> >
> > Now that the infoframe hooks are part of the intel_dig_port, we can use
> > the normal .write_infoframe() hook to update the VSC SDP. We do need to
> > deal with the size difference between the VSC DIP and the others though.
> >
> > Another minor snag is that the compiler will complain to use if we keep
> > using enum hdmi_infoframe_type type and passing in the DP define instead,
> > so et's just change to unsigned int all over for the inforframe type.
> >
> > Signed-off-by: Ville Syrjälä 
> > ---
> >   drivers/gpu/drm/i915/intel_drv.h  |  2 +-
> >   drivers/gpu/drm/i915/intel_hdmi.c | 26 +++--
> >   drivers/gpu/drm/i915/intel_psr.c  | 41 
> > ---
> >   3 files changed, 25 insertions(+), 44 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 4c8451e3d8f1..5dcaa14ff90d 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -900,7 +900,7 @@ struct intel_digital_port {
> > /* for communication with audio component; protected by av_mutex */
> > const struct drm_connector *audio_connector;
> > void (*write_infoframe)(struct drm_encoder *encoder,
> > -   enum hdmi_infoframe_type type,
> > +   unsigned int type,
> > const void *frame, ssize_t len);
> > void (*set_infoframes)(struct drm_encoder *encoder,
> >bool enable,
> > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> > b/drivers/gpu/drm/i915/intel_hdmi.c
> > index 637b17baf798..600a58210450 100644
> > --- a/drivers/gpu/drm/i915/intel_hdmi.c
> > +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> > @@ -68,7 +68,7 @@ static struct intel_hdmi *intel_attached_hdmi(struct 
> > drm_connector *connector)
> > return enc_to_intel_hdmi(_attached_encoder(connector)->base);
> >   }
> >
> > -static u32 g4x_infoframe_index(enum hdmi_infoframe_type type)
> > +static u32 g4x_infoframe_index(unsigned int type)
> >   {
> > switch (type) {
> > case HDMI_INFOFRAME_TYPE_AVI:
> > @@ -83,7 +83,7 @@ static u32 g4x_infoframe_index(enum hdmi_infoframe_type 
> > type)
> > }
> >   }
> >
> > -static u32 g4x_infoframe_enable(enum hdmi_infoframe_type type)
> > +static u32 g4x_infoframe_enable(unsigned int type)
> >   {
> > switch (type) {
> > case HDMI_INFOFRAME_TYPE_AVI:
> > @@ -98,9 +98,11 @@ static u32 g4x_infoframe_enable(enum hdmi_infoframe_type 
> > type)
> > }
> >   }
> >
> > -static u32 hsw_infoframe_enable(enum hdmi_infoframe_type type)
> > +static u32 hsw_infoframe_enable(unsigned int type)
> >   {
> > switch (type) {
> > +   case DP_SDP_VSC:
> Why do we need a new field like this ? Would it make sense to set the 
> type itself as "HDMI_INFOFRAME_TYPE_AVI" ?

We want to enable/write the VSC, not the AVI.

> > +   return VIDEO_DIP_ENABLE_VSC_HSW;
> > case HDMI_INFOFRAME_TYPE_AVI:
> > return VIDEO_DIP_ENABLE_AVI_HSW;
> > case HDMI_INFOFRAME_TYPE_SPD:
> > @@ -116,10 +118,12 @@ static u32 hsw_infoframe_enable(enum 
> > hdmi_infoframe_type type)
> >   static i915_reg_t
> >   hsw_dip_data_reg(struct drm_i915_private *dev_priv,
> >  enum transcoder cpu_transcoder,
> > -enum hdmi_infoframe_type type,
> > +unsigned int type,
> >  int i)
> >   {
> > switch (type) {
> > +   case DP_SDP_VSC:
> > +   return HSW_TVIDEO_DIP_VSC_DATA(cpu_transcoder, i);
> > case HDMI_INFOFRAME_TYPE_AVI:
> > return HSW_TVIDEO_DIP_AVI_DATA(cpu_transcoder, i);
> > case HDMI_INFOFRAME_TYPE_SPD:
> > @@ -133,7 +137,7 @@ hsw_dip_data_reg(struct drm_i915_private *dev_priv,
> >   }
> >
> >   static void g4x_write_infoframe(struct drm_encoder *encoder,
> > -   enum hdmi_infoframe_type type,
> > +   unsigned int type,
> > const void *frame, ssize_t len)
> >   {
> > const uint32_t *data = frame;
> > @@ -187,7 +191,7 @@ static bool g4x_infoframe_enabled(struct drm_encoder 
> > *encoder,
> >   }
> >
> >   static void ibx_write_infoframe(struct drm_encoder *encoder,
> > -   enum hdmi_infoframe_type type,
> > +   unsigned int type,
> > const void *frame, ssize_t len)
> >   {
> > const uint32_t *data = frame;
> > @@ -246,7 +250,7 @@ static bool ibx_infoframe_enabled(struct drm_encoder 
> > *encoder,
> >   }
> >
> >   static void cpt_write_infoframe(struct drm_encoder *encoder,
> > -   enum hdmi_infoframe_type type,
> > +   unsigned int type,
> > 

Re: [Intel-gfx] [PATCH 4/7] drm/i915: Move infoframe vfuncs into intel_digital_port

[Ville Syrjälä]

On Mon, Jun 13, 2016 at 03:47:13PM +0530, Sharma, Shashank wrote:
> Regards
> Shashank
> 
> On 6/3/2016 1:25 AM, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> >
> > DP ports will also want to utilize the video DIP for SDP transmission.
> > So let's move the vfuncs into the dig_port.
> >
> > Signed-off-by: Ville Syrjälä 
> > ---
> >   drivers/gpu/drm/i915/intel_ddi.c  | 20 ++--
> >   drivers/gpu/drm/i915/intel_drv.h  | 16 +-
> >   drivers/gpu/drm/i915/intel_hdmi.c | 64 
> > ---
> >   3 files changed, 52 insertions(+), 48 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index 6ff2a7b97ca6..3a882a979e5d 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -1628,11 +1628,12 @@ static void intel_ddi_pre_enable(struct 
> > intel_encoder *intel_encoder)
> > if (port != PORT_A || INTEL_INFO(dev_priv)->gen >= 9)
> > intel_dp_stop_link_train(intel_dp);
> > } else if (type == INTEL_OUTPUT_HDMI) {
> > -   struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
> > +   struct intel_digital_port *intel_dig_port =
> > +   enc_to_dig_port(encoder);
> >
> > -   intel_hdmi->set_infoframes(encoder,
> > -  crtc->config->has_infoframe,
> > -  >config->base.adjusted_mode);
> > +   intel_dig_port->set_infoframes(encoder,
> > +  crtc->config->has_infoframe,
> > +
> We have kept this call still inside if (type == HDMI); now when the aim 
> is to make it common for all DDI interfaces, do we need this check ?
>  
> >config->base.adjusted_mode);

This is a purely mechanical change. No change in behaviour.

> > }
> >   }
> >
> > @@ -1662,9 +1663,10 @@ static void intel_ddi_post_disable(struct 
> > intel_encoder *intel_encoder)
> > intel_wait_ddi_buf_idle(dev_priv, port);
> >
> > if (type == INTEL_OUTPUT_HDMI) {
> > -   struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
> > +   struct intel_digital_port *intel_dig_port =
> > +   enc_to_dig_port(encoder);
> >
> > -   intel_hdmi->set_infoframes(encoder, false, NULL);
> > +   intel_dig_port->set_infoframes(encoder, false, NULL);
> Same as above.
> > }
> >
> > if (type == INTEL_OUTPUT_DISPLAYPORT || type == INTEL_OUTPUT_EDP) {
> > @@ -2155,7 +2157,7 @@ void intel_ddi_get_config(struct intel_encoder 
> > *encoder,
> > struct drm_i915_private *dev_priv = encoder->base.dev->dev_private;
> > struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
> > enum transcoder cpu_transcoder = pipe_config->cpu_transcoder;
> > -   struct intel_hdmi *intel_hdmi;
> > +   struct intel_digital_port *intel_dig_port;
> > u32 temp, flags = 0;
> >
> > /* XXX: DSI transcoder paranoia */
> > @@ -2194,9 +2196,9 @@ void intel_ddi_get_config(struct intel_encoder 
> > *encoder,
> > switch (temp & TRANS_DDI_MODE_SELECT_MASK) {
> > case TRANS_DDI_MODE_SELECT_HDMI:
>   case TRANS_DDI_MODE_SELECT_DP here: ?
> > pipe_config->has_hdmi_sink = true;
> > -   intel_hdmi = enc_to_intel_hdmi(>base);
> > +   intel_dig_port = enc_to_dig_port(>base);
> >
> > -   if (intel_hdmi->infoframe_enabled(>base, pipe_config))
> > +   if (intel_dig_port->infoframe_enabled(>base, 
> > pipe_config))
> > pipe_config->has_infoframe = true;
> > /* fall through */
> > case TRANS_DDI_MODE_SELECT_DVI:
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index ebe7b3427e2e..a607799b7776 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -790,14 +790,6 @@ struct intel_hdmi {
> > bool rgb_quant_range_selectable;
> > enum hdmi_picture_aspect aspect_ratio;
> > struct intel_connector *attached_connector;
> > -   void (*write_infoframe)(struct drm_encoder *encoder,
> > -   enum hdmi_infoframe_type type,
> > -   const void *frame, ssize_t len);
> > -   void (*set_infoframes)(struct drm_encoder *encoder,
> > -  bool enable,
> > -  const struct drm_display_mode *adjusted_mode);
> > -   bool (*infoframe_enabled)(struct drm_encoder *encoder,
> > - const struct intel_crtc_state *pipe_config);
> >   };
> >
> >   struct intel_dp_mst_encoder;
> > @@ -907,6 +899,14 @@ struct intel_digital_port {
> > uint8_t max_lanes;
> > /* for communication with audio component; protected by av_mutex */
> > const struct drm_connector *audio_connector;
> > +   void 

Re: [Intel-gfx] [PATCH 3/7] drm/i915: Disable infoframes when shutting down DDI HDMI

[Ville Syrjälä]

On Mon, Jun 13, 2016 at 03:36:19PM +0530, Sharma, Shashank wrote:
> Regards
> Shashank
> 
> On 6/3/2016 1:25 AM, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> >
> > Disabling the video DIP when shutting the port down seems like a good
> > idea.
> >
> > Bspec says:
> > "When disabling both the DIP port and DIP transmission,
> >   first disable the port and then disable DIP."
> > and
> > "Restriction : GCP is only supported with HDMI when the bits per color is
> >   not equal to 8. GCP must be enabled prior to enabling TRANS_DDI_FUNC_CTL
> >   for HDMI with bits per color not equal to 8 and disabled after disabling
> >   TRANS_DDI_FUNC_CTL"
> >
> > So let's do it in the .post_disable() hook.
> >
> > Signed-off-by: Ville Syrjälä 
> > ---
> >   drivers/gpu/drm/i915/intel_ddi.c | 6 ++
> >   1 file changed, 6 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index 2fb28d310c22..6ff2a7b97ca6 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -1661,6 +1661,12 @@ static void intel_ddi_post_disable(struct 
> > intel_encoder *intel_encoder)
> > if (wait)
> > intel_wait_ddi_buf_idle(dev_priv, port);
> >
> > +   if (type == INTEL_OUTPUT_HDMI) {
> > +   struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
> > +
> > +   intel_hdmi->set_infoframes(encoder, false, NULL);
> I have seen an assert_hdmi_port_disabled in hsw_set_infoframes, it will 
> cause assert.

No. We've already turned off the port by this time.

> > +   }
> > +
> > if (type == INTEL_OUTPUT_DISPLAYPORT || type == INTEL_OUTPUT_EDP) {
> > struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> > intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
> >

-- 
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 2/7] drm/i915: Check has_infoframes when enabling infoframes

[Ville Syrjälä]

On Mon, Jun 13, 2016 at 01:40:50PM +0530, Sharma, Shashank wrote:
> Regards
> Shashank
> 
> On 6/3/2016 1:25 AM, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> >
> > has_infoframe is what tells us whether infoframes should be enabled, so
> > let's pass that instead of has_hdmi_sink to .set_infoframes().
> >
> > Signed-off-by: Ville Syrjälä 
> > ---
> >   drivers/gpu/drm/i915/intel_ddi.c  | 2 +-
> >   drivers/gpu/drm/i915/intel_hdmi.c | 6 +++---
> >   2 files changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index 022b41d422dc..2fb28d310c22 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -1631,7 +1631,7 @@ static void intel_ddi_pre_enable(struct intel_encoder 
> > *intel_encoder)
> > struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
> >
> > intel_hdmi->set_infoframes(encoder,
> > -  crtc->config->has_hdmi_sink,
> > +  crtc->config->has_infoframe,
> I am a bit confused here, please correct me if I am not going in right 
> direction, but what if its a DVI device which still needs video/AVI 
> infoframes but can drop Audio IF ? Wont it make more sense to keep using 
> has_hdmi_sink ?

DVI doesn't do infoframes, so not sure what you're asking here. Also we
don't deal with audio infoframes here.

> >>config->base.adjusted_mode);
> > }
> >   }
> > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> > b/drivers/gpu/drm/i915/intel_hdmi.c
> > index eb455ea6ea92..067b10a7cb04 100644
> > --- a/drivers/gpu/drm/i915/intel_hdmi.c
> > +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> > @@ -1665,7 +1665,7 @@ static void intel_hdmi_pre_enable(struct 
> > intel_encoder *encoder)
> > intel_hdmi_prepare(encoder);
> >
> > intel_hdmi->set_infoframes(>base,
> > -  intel_crtc->config->has_hdmi_sink,
> > +  intel_crtc->config->has_infoframe,
> Same as above
> 
> Regards
> Shashank
> >adjusted_mode);
> >   }
> >
> > @@ -1686,7 +1686,7 @@ static void vlv_hdmi_pre_enable(struct intel_encoder 
> > *encoder)
> >  0x2b247878);
> >
> > intel_hdmi->set_infoframes(>base,
> > -  intel_crtc->config->has_hdmi_sink,
> > +  intel_crtc->config->has_infoframe,
> >adjusted_mode);
> >
> > g4x_enable_hdmi(encoder);
> > @@ -1749,7 +1749,7 @@ static void chv_hdmi_pre_enable(struct intel_encoder 
> > *encoder)
> > chv_set_phy_signal_level(encoder, 128, 102, false);
> >
> > intel_hdmi->set_infoframes(>base,
> > -  intel_crtc->config->has_hdmi_sink,
> > +  intel_crtc->config->has_infoframe,
> >adjusted_mode);
> >
> > g4x_enable_hdmi(encoder);
> >

-- 
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 6/7] drm/i915: Remove mostly duplicated video DIP handling from PSR code

[Sharma, Shashank]

Regards
Shashank

On 6/3/2016 1:25 AM, ville.syrj...@linux.intel.com wrote:

From: Ville Syrjälä 

Now that the infoframe hooks are part of the intel_dig_port, we can use
the normal .write_infoframe() hook to update the VSC SDP. We do need to
deal with the size difference between the VSC DIP and the others though.

Another minor snag is that the compiler will complain to use if we keep
using enum hdmi_infoframe_type type and passing in the DP define instead,
so et's just change to unsigned int all over for the inforframe type.

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

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 4c8451e3d8f1..5dcaa14ff90d 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -900,7 +900,7 @@ struct intel_digital_port {
/* for communication with audio component; protected by av_mutex */
const struct drm_connector *audio_connector;
void (*write_infoframe)(struct drm_encoder *encoder,
-   enum hdmi_infoframe_type type,
+   unsigned int type,
const void *frame, ssize_t len);
void (*set_infoframes)(struct drm_encoder *encoder,
   bool enable,
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 637b17baf798..600a58210450 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -68,7 +68,7 @@ static struct intel_hdmi *intel_attached_hdmi(struct 
drm_connector *connector)
return enc_to_intel_hdmi(_attached_encoder(connector)->base);
  }

-static u32 g4x_infoframe_index(enum hdmi_infoframe_type type)
+static u32 g4x_infoframe_index(unsigned int type)
  {
switch (type) {
case HDMI_INFOFRAME_TYPE_AVI:
@@ -83,7 +83,7 @@ static u32 g4x_infoframe_index(enum hdmi_infoframe_type type)
}
  }

-static u32 g4x_infoframe_enable(enum hdmi_infoframe_type type)
+static u32 g4x_infoframe_enable(unsigned int type)
  {
switch (type) {
case HDMI_INFOFRAME_TYPE_AVI:
@@ -98,9 +98,11 @@ static u32 g4x_infoframe_enable(enum hdmi_infoframe_type 
type)
}
  }

-static u32 hsw_infoframe_enable(enum hdmi_infoframe_type type)
+static u32 hsw_infoframe_enable(unsigned int type)
  {
switch (type) {
+   case DP_SDP_VSC:
Why do we need a new field like this ? Would it make sense to set the 
type itself as "HDMI_INFOFRAME_TYPE_AVI" ?

+   return VIDEO_DIP_ENABLE_VSC_HSW;
case HDMI_INFOFRAME_TYPE_AVI:
return VIDEO_DIP_ENABLE_AVI_HSW;
case HDMI_INFOFRAME_TYPE_SPD:
@@ -116,10 +118,12 @@ static u32 hsw_infoframe_enable(enum hdmi_infoframe_type 
type)
  static i915_reg_t
  hsw_dip_data_reg(struct drm_i915_private *dev_priv,
 enum transcoder cpu_transcoder,
-enum hdmi_infoframe_type type,
+unsigned int type,
 int i)
  {
switch (type) {
+   case DP_SDP_VSC:
+   return HSW_TVIDEO_DIP_VSC_DATA(cpu_transcoder, i);
case HDMI_INFOFRAME_TYPE_AVI:
return HSW_TVIDEO_DIP_AVI_DATA(cpu_transcoder, i);
case HDMI_INFOFRAME_TYPE_SPD:
@@ -133,7 +137,7 @@ hsw_dip_data_reg(struct drm_i915_private *dev_priv,
  }

  static void g4x_write_infoframe(struct drm_encoder *encoder,
-   enum hdmi_infoframe_type type,
+   unsigned int type,
const void *frame, ssize_t len)
  {
const uint32_t *data = frame;
@@ -187,7 +191,7 @@ static bool g4x_infoframe_enabled(struct drm_encoder 
*encoder,
  }

  static void ibx_write_infoframe(struct drm_encoder *encoder,
-   enum hdmi_infoframe_type type,
+   unsigned int type,
const void *frame, ssize_t len)
  {
const uint32_t *data = frame;
@@ -246,7 +250,7 @@ static bool ibx_infoframe_enabled(struct drm_encoder 
*encoder,
  }

  static void cpt_write_infoframe(struct drm_encoder *encoder,
-   enum hdmi_infoframe_type type,
+   unsigned int type,
const void *frame, ssize_t len)
  {
const uint32_t *data = frame;
@@ -303,7 +307,7 @@ static bool cpt_infoframe_enabled(struct drm_encoder 
*encoder,
  }

  static void vlv_write_infoframe(struct drm_encoder *encoder,
-   enum hdmi_infoframe_type type,
+   unsigned int type,
const void *frame, ssize_t 

Re: [Intel-gfx] [PATCH v3] drm/i915/gen9: implement WaConextSwitchWithConcurrentTLBInvalidate

[Arun Siluvery]

On 13/06/2016 16:45, tim.g...@intel.com wrote:

From: Tim Gore 

This patch enables a workaround for a mid thread preemption
issue where a hardware timing problem can prevent the
context restore from happening, leading to a hang.

v2: move to gen9_init_workarounds (Arun)
v3: move to start of gen9_init_workarounds (Arun)

Signed-off-by: Tim Gore 
---
  drivers/gpu/drm/i915/i915_reg.h | 4 
  drivers/gpu/drm/i915/intel_ringbuffer.c | 3 +++
  2 files changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 81d1896..2a6fc62 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1810,6 +1810,10 @@ enum skl_disp_power_wells {
  #define   GEN9_IZ_HASHING_MASK(slice) (0x3 << ((slice) * 2))
  #define   GEN9_IZ_HASHING(slice, val) ((val) << ((slice) * 2))

+/* chicken reg for WaConextSwitchWithConcurrentTLBInvalidate */
+#define GEN9_CSFE_CHICKEN1_RCS _MMIO(0x20D4)
+#define   GEN9_PREEMPT_GPGPU_SYNC_SWITCH_DISABLE (1 << 2)
+
  /* WaClearTdlStateAckDirtyBits */
  #define GEN8_STATE_ACK_MMIO(0x20F0)
  #define GEN9_STATE_ACK_SLICE1 _MMIO(0x20F8)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index cf8d0bf..110c7fc 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -910,6 +910,9 @@ static int gen9_init_workarounds(struct intel_engine_cs 
*engine)
struct drm_i915_private *dev_priv = engine->i915;
int ret;

+   /* WaConextSwitchWithConcurrentTLBInvalidate:skl,bxt,kbl */
+   I915_WRITE(GEN9_CSFE_CHICKEN1_RCS, 
_MASKED_BIT_ENABLE(GEN9_PREEMPT_GPGPU_SYNC_SWITCH_DISABLE));
+
agrees with spec. It would've been good to have correct spelling but to 
match with existing documentation we have to use the same name.


Reviewed-by: Arun Siluvery 

regards
Arun


/* WaEnableLbsSlaRetryTimerDecrement:skl,bxt,kbl */
I915_WRITE(BDW_SCRATCH1, I915_READ(BDW_SCRATCH1) |
   GEN9_LBS_SLA_RETRY_TIMER_DECREMENT_ENABLE);



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

Re: [Intel-gfx] [PATCH] drm/i915/fbc: disable FBC on FIFO underruns

[Stefan Richter]

On Jun 10 Paulo Zanoni wrote:
> Since my test machines don't produce FIFO underrun errors, I tested this by
> creating a debugfs file that just calls intel_fbc_handle_fifo_underrun(). I'd
> appreciate some Tested-by tags, if possible.

Since May 8 I have been using 4.6.0-rc6 patched with
drm-intel-nightly_2016y-05m-06d-14h-29m-58s (from what I understand,
something close to what is now in mainline), and fbc disabled on the
kernel commandline.  I have not rebooted since May 8.

For that kernel, i915.enable_fbc=0 is both required and sufficient to
prevent freezes at random points in time (as reported).  The
drm-intel-nightly_2016y-05m-06d-14h-29m-58s patch on the other hand has the
effect that there are never any FIFO underruns logged anymore.

If there are no FIFO underruns reported in dmesg, your underrun
detection routine would never hit, would it?

If you nevertheless think it's worth trying, should I test it on top of
4.7-rc3 or on current drm-intel-nightly?
-- 
Stefan Richter
-==- -==- -==-=
http://arcgraph.de/sr/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 5/7] drm/i915: Init infoframe vfuncs for DP encoders as well

[Sharma, Shashank]

Reviewed-by: Shashank Sharma

Regards
Shashank

On 6/3/2016 1:25 AM, ville.syrj...@linux.intel.com wrote:

From: Ville Syrjälä 

DP ports may want to use the video DIP for SDP transmission, so let's
initiialize the vfuncs for DP encoders as well. The only exception is
port A eDP prior to HSW as that one doesn't have a video DIP instance.

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

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 3a882a979e5d..c5611e9d9b9c 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2392,6 +2392,8 @@ void intel_ddi_init(struct drm_device *dev, enum port 
port)
intel_encoder->crtc_mask = (1 << 0) | (1 << 1) | (1 << 2);
intel_encoder->cloneable = 0;

+   intel_infoframe_init(intel_dig_port);
+
if (init_dp) {
if (!intel_ddi_init_dp_connector(intel_dig_port))
goto err;
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f97cd5305e4c..a2d0ee363307 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5637,6 +5637,9 @@ bool intel_dp_init(struct drm_device *dev,
intel_dig_port->hpd_pulse = intel_dp_hpd_pulse;
dev_priv->hotplug.irq_port[port] = intel_dig_port;

+   if (port != PORT_A)
+   intel_infoframe_init(intel_dig_port);
+
if (!intel_dp_init_connector(intel_dig_port, intel_connector))
goto err_init_connector;

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index a607799b7776..4c8451e3d8f1 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1445,6 +1445,7 @@ struct intel_hdmi *enc_to_intel_hdmi(struct drm_encoder 
*encoder);
  bool intel_hdmi_compute_config(struct intel_encoder *encoder,
   struct intel_crtc_state *pipe_config);
  void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi *hdmi, bool enable);
+void intel_infoframe_init(struct intel_digital_port *intel_dig_port);


  /* intel_lvds.c */
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 319f5013923c..637b17baf798 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1801,6 +1801,33 @@ intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, 
struct drm_connector *c
intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
  }

+void intel_infoframe_init(struct intel_digital_port *intel_dig_port)
+{
+   struct drm_device *dev = intel_dig_port->base.base.dev;
+
+   if (IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev)) {
+   intel_dig_port->write_infoframe = vlv_write_infoframe;
+   intel_dig_port->set_infoframes = vlv_set_infoframes;
+   intel_dig_port->infoframe_enabled = vlv_infoframe_enabled;
+   } else if (IS_G4X(dev)) {
+   intel_dig_port->write_infoframe = g4x_write_infoframe;
+   intel_dig_port->set_infoframes = g4x_set_infoframes;
+   intel_dig_port->infoframe_enabled = g4x_infoframe_enabled;
+   } else if (HAS_DDI(dev)) {
+   intel_dig_port->write_infoframe = hsw_write_infoframe;
+   intel_dig_port->set_infoframes = hsw_set_infoframes;
+   intel_dig_port->infoframe_enabled = hsw_infoframe_enabled;
+   } else if (HAS_PCH_IBX(dev)) {
+   intel_dig_port->write_infoframe = ibx_write_infoframe;
+   intel_dig_port->set_infoframes = ibx_set_infoframes;
+   intel_dig_port->infoframe_enabled = ibx_infoframe_enabled;
+   } else {
+   intel_dig_port->write_infoframe = cpt_write_infoframe;
+   intel_dig_port->set_infoframes = cpt_set_infoframes;
+   intel_dig_port->infoframe_enabled = cpt_infoframe_enabled;
+   }
+}
+
  void intel_hdmi_init_connector(struct intel_digital_port *intel_dig_port,
   struct intel_connector *intel_connector)
  {
@@ -1883,28 +1910,6 @@ void intel_hdmi_init_connector(struct intel_digital_port 
*intel_dig_port,
BUG();
}

-   if (IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev)) {
-   intel_dig_port->write_infoframe = vlv_write_infoframe;
-   intel_dig_port->set_infoframes = vlv_set_infoframes;
-   intel_dig_port->infoframe_enabled = vlv_infoframe_enabled;
-   } else if (IS_G4X(dev)) {
-   intel_dig_port->write_infoframe = g4x_write_infoframe;
-   intel_dig_port->set_infoframes = g4x_set_infoframes;
-   intel_dig_port->infoframe_enabled 

[Intel-gfx] ✗ Ro.CI.BAT: warning for drm/i915/gen9: implement WaConextSwitchWithConcurrentTLBInvalidate (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/gen9: implement WaConextSwitchWithConcurrentTLBInvalidate 
(rev3)
URL   : https://patchwork.freedesktop.org/series/8487/
State : warning

== Summary ==

Series 8487v3 drm/i915/gen9: implement WaConextSwitchWithConcurrentTLBInvalidate
http://patchwork.freedesktop.org/api/1.0/series/8487/revisions/3/mbox

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-cmd:
fail   -> PASS   (ro-byt-n2820)
Test gem_exec_suspend:
Subgroup basic-s3:
pass   -> DMESG-WARN (ro-bdw-i7-5557U)
Test kms_force_connector_basic:
Subgroup force-connector-state:
skip   -> PASS   (ro-ivb2-i7-3770)
Subgroup force-edid:
skip   -> PASS   (ro-ivb2-i7-3770)
Subgroup prune-stale-modes:
skip   -> PASS   (ro-ivb2-i7-3770)
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-b:
pass   -> SKIP   (fi-skl-i5-6260u)
Subgroup suspend-read-crc-pipe-b:
skip   -> DMESG-WARN (ro-bdw-i7-5557U)
Subgroup suspend-read-crc-pipe-c:
dmesg-warn -> SKIP   (ro-bdw-i5-5250u)

fi-bdw-i7-5557u  total:213  pass:201  dwarn:0   dfail:0   fail:0   skip:12 
fi-skl-i5-6260u  total:213  pass:201  dwarn:0   dfail:0   fail:0   skip:12 
fi-skl-i7-6700k  total:213  pass:188  dwarn:0   dfail:0   fail:0   skip:25 
fi-snb-i7-2600   total:213  pass:174  dwarn:0   dfail:0   fail:0   skip:39 
ro-bdw-i5-5250u  total:213  pass:197  dwarn:1   dfail:0   fail:0   skip:15 
ro-bdw-i7-5557U  total:213  pass:197  dwarn:2   dfail:0   fail:0   skip:14 
ro-bdw-i7-5600u  total:213  pass:185  dwarn:0   dfail:0   fail:0   skip:28 
ro-bsw-n3050 total:213  pass:172  dwarn:0   dfail:0   fail:2   skip:39 
ro-byt-n2820 total:213  pass:174  dwarn:0   dfail:0   fail:2   skip:37 
ro-hsw-i3-4010u  total:213  pass:190  dwarn:0   dfail:0   fail:0   skip:23 
ro-hsw-i7-4770r  total:213  pass:190  dwarn:0   dfail:0   fail:0   skip:23 
ro-ilk-i7-620lm  total:213  pass:150  dwarn:0   dfail:0   fail:1   skip:62 
ro-ilk1-i5-650   total:208  pass:150  dwarn:0   dfail:0   fail:1   skip:57 
ro-ivb-i7-3770   total:213  pass:181  dwarn:0   dfail:0   fail:0   skip:32 
ro-ivb2-i7-3770  total:213  pass:185  dwarn:0   dfail:0   fail:0   skip:28 
ro-skl3-i5-6260u total:213  pass:201  dwarn:1   dfail:0   fail:0   skip:11 
ro-snb-i7-2620M  total:213  pass:174  dwarn:0   dfail:0   fail:1   skip:38 
fi-hsw-i7-4770k failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1171/

f80cfb4 drm-intel-nightly: 2016y-06m-13d-10h-41m-19s UTC integration manifest
3f1502e drm/i915/gen9: implement WaConextSwitchWithConcurrentTLBInvalidate

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

[Intel-gfx] [PATCH v3] drm/i915/gen9: implement WaConextSwitchWithConcurrentTLBInvalidate

[tim . gore]

From: Tim Gore 

This patch enables a workaround for a mid thread preemption
issue where a hardware timing problem can prevent the
context restore from happening, leading to a hang.

v2: move to gen9_init_workarounds (Arun)
v3: move to start of gen9_init_workarounds (Arun)

Signed-off-by: Tim Gore 
---
 drivers/gpu/drm/i915/i915_reg.h | 4 
 drivers/gpu/drm/i915/intel_ringbuffer.c | 3 +++
 2 files changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 81d1896..2a6fc62 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1810,6 +1810,10 @@ enum skl_disp_power_wells {
 #define   GEN9_IZ_HASHING_MASK(slice)  (0x3 << ((slice) * 2))
 #define   GEN9_IZ_HASHING(slice, val)  ((val) << ((slice) * 2))
 
+/* chicken reg for WaConextSwitchWithConcurrentTLBInvalidate */
+#define GEN9_CSFE_CHICKEN1_RCS _MMIO(0x20D4)
+#define   GEN9_PREEMPT_GPGPU_SYNC_SWITCH_DISABLE (1 << 2)
+
 /* WaClearTdlStateAckDirtyBits */
 #define GEN8_STATE_ACK _MMIO(0x20F0)
 #define GEN9_STATE_ACK_SLICE1  _MMIO(0x20F8)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index cf8d0bf..110c7fc 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -910,6 +910,9 @@ static int gen9_init_workarounds(struct intel_engine_cs 
*engine)
struct drm_i915_private *dev_priv = engine->i915;
int ret;
 
+   /* WaConextSwitchWithConcurrentTLBInvalidate:skl,bxt,kbl */
+   I915_WRITE(GEN9_CSFE_CHICKEN1_RCS, 
_MASKED_BIT_ENABLE(GEN9_PREEMPT_GPGPU_SYNC_SWITCH_DISABLE));
+
/* WaEnableLbsSlaRetryTimerDecrement:skl,bxt,kbl */
I915_WRITE(BDW_SCRATCH1, I915_READ(BDW_SCRATCH1) |
   GEN9_LBS_SLA_RETRY_TIMER_DECREMENT_ENABLE);
-- 
1.9.1

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

[Intel-gfx] [drm:intel_set_cpu_fifo_underrun_reporting]

[Petko Manolov]

Hello guys,

Running xorg on my Lenovo Yoga 2 Pro (MY2013) on recent kernels turn into a 
major PITA.  After a couple of minutes the screen starts to flicker and only 
killing xorg or reboot fixes the problem.  This is what i typically see in 
dmesg:


[0.00] microcode: microcode updated early to revision 0x1d, date = 
2015-08-13
[0.00] Linux version 4.7.0-rc3 (petkan@yoga) (gcc version 6.1.1 
20160519 (Debian 6.1.1-4) ) #5 SMP Mon Jun 13 12:41:31 EEST 2016
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.7.0-rc3 root=/dev/sda1 
ro quiet
...
[0.104213] smpboot: CPU0: Intel(R) Core(TM) i7-4500U CPU @ 1.80GHz (family: 
0x6, model: 0x45, stepping: 0x1)
...
[1.033691] [drm] Initialized drm 1.1.0 20060810
[1.034106] [drm] Memory usable by graphics device = 2048M
[1.034108] [drm] Replacing VGA console driver
[1.040787] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[1.040788] [drm] Driver supports precise vblank timestamp query.
[1.066820] [drm] Initialized i915 1.6.0 20160425 for :00:02.0 on minor 0
[1.231007] fbcon: inteldrmfb (fb0) is primary device
[2.524538] i915 :00:02.0: fb0: inteldrmfb frame buffer device
...
[   92.825302] [drm:intel_set_cpu_fifo_underrun_reporting] *ERROR* uncleared 
fifo underrun on pipe A
[   92.825312] [drm:ironlake_irq_handler] *ERROR* CPU pipe A FIFO underrun


This is going on for all v4.6 kernel releases as well as v4.7-rcX.  Older, v4.4 
and v4.5, kernels are running fine.  I'm using Debian testing updated to 
2016-06-13.

I'd be happy to help with testing so please let me know if there's anything i 
can do for you.


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

Re: [Intel-gfx] [PATCH v2 5/6] drm/i915/guc: refactor doorbell management code

[Tvrtko Ursulin]

On 13/06/16 11:25, Dave Gordon wrote:

On 13/06/16 10:48, Tvrtko Ursulin wrote:


On 10/06/16 17:51, Dave Gordon wrote:

This patch refactors the driver's handling and tracking of doorbells, in
preparation for a later one which will resolve a suspend-resume issue.

There are three resources to be managed:
1. Cachelines: a single line within the client-object's page 0
is snooped by doorbell hardware for writes from the host.
2. Doorbell registers: each defines one cacheline to be snooped.
3. Bitmap: tracks which doorbell registers are in use.

The doorbell setup/teardown protocol starts with:
1. Pick a cacheline: select_doorbell_cacheline()
2. Find an available doorbell register: assign_doorbell()
(These values are passed to the GuC via the shared context
descriptor; this part of the sequence remains unchanged).

3. Update the bitmap to reflect registers-in-use
4. Prepare the cacheline for use by setting its status to ENABLED
5. Ask the GuC to program the doorbell to snoop the cacheline

and of course teardown is very similar:
6. Set the cacheline to DISABLED
7. Ask the GuC to reprogram the doorbell to stop snooping
8. Record that the doorbell is not in use.

Operations 6-8 (guc_disable_doorbell(), host2guc_release_doorbell(), and
release_doorbell()) were called in sequence from guc_client_free(), but
are now moved into the teardown phase of the common function.

Steps 4-5 (guc_init_doorbell() and host2guc_allocate_doorbell()) were
similarly done as sequential steps in guc_client_alloc(), but since it
turns out that we don't need to be able to do them separately they're
now collected into the setup phase of the common function.

The only new code (and new capability) is the block tagged
 /* Update the GuC's idea of the doorbell ID */
i.e. we can now *change* the doorbell register used by an existing
client, whereas previously it was set once for the entire lifetime
of the client. We will use this new feature in the next patch.

v2: Trivial independent fixes pushed ahead as separate patches.
 MUCH longer commit message :) [Tvrtko Ursulin]

Signed-off-by: Dave Gordon 
---
  drivers/gpu/drm/i915/i915_guc_submission.c | 94
+-
  1 file changed, 53 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 45b33f8..1833bfd 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -174,31 +174,59 @@ static int host2guc_sample_forcewake(struct
intel_guc *guc,
   * client object which contains the page being used for the doorbell
   */

-static void guc_init_doorbell(struct intel_guc *guc,
-  struct i915_guc_client *client)
+static int guc_update_doorbell_id(struct intel_guc *guc,
+  struct i915_guc_client *client,
+  u16 new_id)
  {
+struct sg_table *sg = guc->ctx_pool_obj->pages;
+void *doorbell_bitmap = guc->doorbell_bitmap;
  struct guc_doorbell_info *doorbell;
+struct guc_context_desc desc;
+size_t len;

  doorbell = client->client_base + client->doorbell_offset;

-doorbell->db_status = GUC_DOORBELL_ENABLED;
+if (client->doorbell_id != GUC_INVALID_DOORBELL_ID &&
+test_bit(client->doorbell_id, doorbell_bitmap)) {
+/* Deactivate the old doorbell */
+doorbell->db_status = GUC_DOORBELL_DISABLED;
+(void)host2guc_release_doorbell(guc, client);
+__clear_bit(client->doorbell_id, doorbell_bitmap);
+}
+
+/* Update the GuC's idea of the doorbell ID */
+len = sg_pcopy_to_buffer(sg->sgl, sg->nents, , sizeof(desc),
+ sizeof(desc) * client->ctx_index);
+if (len != sizeof(desc))
+return -EFAULT;
+desc.db_id = new_id;
+len = sg_pcopy_from_buffer(sg->sgl, sg->nents, , sizeof(desc),
+ sizeof(desc) * client->ctx_index);
+if (len != sizeof(desc))
+return -EFAULT;
+
+client->doorbell_id = new_id;
+if (new_id == GUC_INVALID_DOORBELL_ID)
+return 0;
+
+/* Activate the new doorbell */
+__set_bit(new_id, doorbell_bitmap);


Is this the same bit as in assign_doorbell so redundant?


It is the same bit, and yes, it will be redundant during the initial
setup, but when we come to *re*assign the association between a client
and a doorbell (in the next patch) then it won't be.

We could also choose to have assign_doorbell() NOT update the map, so
then this would be the only place where the bitmap gets updated. I'd
have to rename it though, as it would no longer be assigning anything!


Maybe pick_doorbell or find_free_doorbell? It would be a little bit 
clearer and safer (early returns above could leave the bitmap set) with 
a single bitmap update location so I think it would be worth it.


Regards,

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

[Intel-gfx] ✓ Ro.CI.BAT: success for series starting with [RESEND,1/7] drm/i915/dsi: don't debug log "missing" sequences

[Patchwork]

== Series Details ==

Series: series starting with [RESEND,1/7] drm/i915/dsi: don't debug log 
"missing" sequences
URL   : https://patchwork.freedesktop.org/series/8611/
State : success

== Summary ==

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

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

fi-bdw-i7-5557u  total:213  pass:201  dwarn:0   dfail:0   fail:0   skip:12 
fi-skl-i5-6260u  total:213  pass:202  dwarn:0   dfail:0   fail:0   skip:11 
fi-skl-i7-6700k  total:213  pass:188  dwarn:0   dfail:0   fail:0   skip:25 
fi-snb-i7-2600   total:213  pass:174  dwarn:0   dfail:0   fail:0   skip:39 
ro-bdw-i5-5250u  total:213  pass:197  dwarn:2   dfail:0   fail:0   skip:14 
ro-bdw-i7-5600u  total:213  pass:185  dwarn:0   dfail:0   fail:0   skip:28 
ro-bsw-n3050 total:213  pass:172  dwarn:0   dfail:0   fail:2   skip:39 
ro-byt-n2820 total:213  pass:173  dwarn:0   dfail:0   fail:3   skip:37 
ro-hsw-i3-4010u  total:213  pass:190  dwarn:0   dfail:0   fail:0   skip:23 
ro-hsw-i7-4770r  total:213  pass:190  dwarn:0   dfail:0   fail:0   skip:23 
ro-ilk-i7-620lm  total:213  pass:149  dwarn:0   dfail:0   fail:2   skip:62 
ro-ilk1-i5-650   total:208  pass:150  dwarn:0   dfail:0   fail:1   skip:57 
ro-ivb-i7-3770   total:213  pass:181  dwarn:0   dfail:0   fail:0   skip:32 
ro-ivb2-i7-3770  total:213  pass:185  dwarn:0   dfail:0   fail:0   skip:28 
ro-skl3-i5-6260u total:213  pass:201  dwarn:1   dfail:0   fail:0   skip:11 
ro-snb-i7-2620M  total:213  pass:174  dwarn:0   dfail:0   fail:1   skip:38 
fi-hsw-i7-4770k failed to connect after reboot
ro-bdw-i7-5557U failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1170/

5aacd93 drm-intel-nightly: 2016y-06m-13d-09h-05m-21s UTC integration manifest
862c3d1 drm/i915/dsi: double check element parsing against size if present
be3d233 drm/i915/bios: log about presence of DSI sequences we do not run
a699949 drm/i915/dsi: run backlight on/off sequences in panel enable/disable 
hooks
b2b9d4e drm/i915/dsi: run power on/off sequences in panel prepare/unprepare 
hooks
5ad85d5 drm/i915/dsi: add skip functions for spi and pmic elements
afb1e77 drm/i915/dsi: add debug logging to element execution
9d6140b drm/i915/dsi: don't debug log "missing" sequences

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

Re: [Intel-gfx] [patch] drm/i915/mocs: || vs | typo in get_mocs_settings()

[Mika Kuoppala]

Dan Carpenter  writes:

> It seems pretty clear that bitwise OR was intended here and not logical
> OR.
>
> Fixes: 6fc29133eafb ('drm/i915/gen9: Add WaDisableSkipCaching')
> Signed-off-by: Dan Carpenter 

Reviewed-by: Mika Kuoppala 

>
> diff --git a/drivers/gpu/drm/i915/intel_mocs.c 
> b/drivers/gpu/drm/i915/intel_mocs.c
> index 8f96c40..3c1482b 100644
> --- a/drivers/gpu/drm/i915/intel_mocs.c
> +++ b/drivers/gpu/drm/i915/intel_mocs.c
> @@ -162,7 +162,7 @@ static bool get_mocs_settings(struct drm_i915_private 
> *dev_priv,
>  
>   for (i = 0; i < table->size; i++)
>   if (WARN_ON(table->table[i].l3cc_value &
> - (L3_ESC(1) || L3_SCC(0x7
> + (L3_ESC(1) | L3_SCC(0x7
>   return false;
>   }
>  
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915/opregion: proper handling of DIDL and CADL (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/opregion: proper handling of DIDL and CADL (rev3)
URL   : https://patchwork.freedesktop.org/series/4783/
State : failure

== Summary ==

Series 4783v3 drm/i915/opregion: proper handling of DIDL and CADL
http://patchwork.freedesktop.org/api/1.0/series/4783/revisions/3/mbox

Test gem_exec_suspend:
Subgroup basic-s3:
pass   -> DMESG-WARN (ro-bdw-i7-5557U)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> SKIP   (ro-bdw-i5-5250u)
Subgroup suspend-read-crc-pipe-c:
skip   -> DMESG-WARN (ro-bdw-i5-5250u)
Test pm_rpm:
Subgroup basic-rte:
pass   -> FAIL   (ro-skl3-i5-6260u)

fi-skl-i7-6700k  total:213  pass:188  dwarn:0   dfail:0   fail:0   skip:25 
ro-bdw-i5-5250u  total:213  pass:197  dwarn:3   dfail:0   fail:0   skip:13 
ro-bdw-i7-5557U  total:213  pass:197  dwarn:1   dfail:0   fail:0   skip:15 
ro-bdw-i7-5600u  total:213  pass:185  dwarn:0   dfail:0   fail:0   skip:28 
ro-bsw-n3050 total:213  pass:172  dwarn:0   dfail:0   fail:2   skip:39 
ro-byt-n2820 total:213  pass:173  dwarn:0   dfail:0   fail:3   skip:37 
ro-hsw-i3-4010u  total:213  pass:190  dwarn:0   dfail:0   fail:0   skip:23 
ro-hsw-i7-4770r  total:213  pass:190  dwarn:0   dfail:0   fail:0   skip:23 
ro-ilk-i7-620lm  total:213  pass:150  dwarn:0   dfail:0   fail:1   skip:62 
ro-ilk1-i5-650   total:208  pass:150  dwarn:0   dfail:0   fail:1   skip:57 
ro-skl3-i5-6260u total:213  pass:200  dwarn:1   dfail:0   fail:1   skip:11 
ro-snb-i7-2620M  total:213  pass:174  dwarn:0   dfail:0   fail:1   skip:38 
fi-bdw-i7-5557u failed to connect after reboot
fi-hsw-i7-4770k failed to connect after reboot
fi-skl-i5-6260u failed to connect after reboot
fi-snb-i7-2600 failed to connect after reboot
ro-ivb2-i7-3770 failed to connect after reboot
ro-ivb-i7-3770 failed to connect after reboot

Results at /archive/results/CI_IGT_test/RO_Patchwork_1169/

5aacd93 drm-intel-nightly: 2016y-06m-13d-09h-05m-21s UTC integration manifest
228155a drm/i915/opregion: update cadl based on actually active outputs
2e7b211 drm/i915: make i915 the source of acpi device ids for _DOD
4a92722 drm/i915/opregion: handle missing connector types for acpi display types
70f121b drm/i915/opregion: abstract acpi display type getter for a connector
8a829b0 drm/i915/opregion: add acpi defines from the spec

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

Re: [Intel-gfx] [PATCH v2 5/5] drm/i915/opregion: update cadl based on actually active outputs

[kbuild test robot]

Hi,

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

url:
https://github.com/0day-ci/linux/commits/Jani-Nikula/drm-i915-opregion-proper-handling-of-DIDL-and-CADL/20160613-173347
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-rhel (attached as .config)
compiler: gcc-4.9 (Debian 4.9.3-14) 4.9.3
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/i915/intel_display.c: In function 'intel_atomic_commit':
>> drivers/gpu/drm/i915/intel_display.c:13836:29: warning: passing argument 1 
>> of 'intel_opregion_update_cadl' from incompatible pointer type
 intel_opregion_update_cadl(dev);
^
   In file included from drivers/gpu/drm/i915/intel_drv.h:32:0,
from drivers/gpu/drm/i915/intel_display.c:36:
   drivers/gpu/drm/i915/i915_drv.h:3666:13: note: expected 'struct 
drm_i915_private *' but argument is of type 'struct drm_device *'
extern void intel_opregion_update_cadl(struct drm_i915_private *dev_priv);
^

vim +/intel_opregion_update_cadl +13836 drivers/gpu/drm/i915/intel_display.c

 13820  
 13821  if (put_domains[i])
 13822  modeset_put_power_domains(dev_priv, 
put_domains[i]);
 13823  
 13824  intel_modeset_verify_crtc(crtc, old_crtc_state, 
crtc->state);
 13825  }
 13826  
 13827  if (intel_state->modeset)
 13828  intel_display_power_put(dev_priv, POWER_DOMAIN_MODESET);
 13829  
 13830  mutex_lock(>struct_mutex);
 13831  drm_atomic_helper_cleanup_planes(dev, state);
 13832  mutex_unlock(>struct_mutex);
 13833  
 13834  drm_atomic_state_free(state);
 13835  
 13836  intel_opregion_update_cadl(dev);
 13837  
 13838  /* As one of the primary mmio accessors, KMS has a high 
likelihood
 13839   * of triggering bugs in unclaimed access. After we finish
 13840   * modesetting, see if an error has been flagged, and if so
 13841   * enable debugging for the next modeset - and hope we catch
 13842   * the culprit.
 13843   *
 13844   * XXX note that we assume display power is on at this point.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 5/6] drm/i915/guc: refactor doorbell management code

[Dave Gordon]

On 13/06/16 10:48, Tvrtko Ursulin wrote:


On 10/06/16 17:51, Dave Gordon wrote:

This patch refactors the driver's handling and tracking of doorbells, in
preparation for a later one which will resolve a suspend-resume issue.

There are three resources to be managed:
1. Cachelines: a single line within the client-object's page 0
is snooped by doorbell hardware for writes from the host.
2. Doorbell registers: each defines one cacheline to be snooped.
3. Bitmap: tracks which doorbell registers are in use.

The doorbell setup/teardown protocol starts with:
1. Pick a cacheline: select_doorbell_cacheline()
2. Find an available doorbell register: assign_doorbell()
(These values are passed to the GuC via the shared context
descriptor; this part of the sequence remains unchanged).

3. Update the bitmap to reflect registers-in-use
4. Prepare the cacheline for use by setting its status to ENABLED
5. Ask the GuC to program the doorbell to snoop the cacheline

and of course teardown is very similar:
6. Set the cacheline to DISABLED
7. Ask the GuC to reprogram the doorbell to stop snooping
8. Record that the doorbell is not in use.

Operations 6-8 (guc_disable_doorbell(), host2guc_release_doorbell(), and
release_doorbell()) were called in sequence from guc_client_free(), but
are now moved into the teardown phase of the common function.

Steps 4-5 (guc_init_doorbell() and host2guc_allocate_doorbell()) were
similarly done as sequential steps in guc_client_alloc(), but since it
turns out that we don't need to be able to do them separately they're
now collected into the setup phase of the common function.

The only new code (and new capability) is the block tagged
 /* Update the GuC's idea of the doorbell ID */
i.e. we can now *change* the doorbell register used by an existing
client, whereas previously it was set once for the entire lifetime
of the client. We will use this new feature in the next patch.

v2: Trivial independent fixes pushed ahead as separate patches.
 MUCH longer commit message :) [Tvrtko Ursulin]

Signed-off-by: Dave Gordon 
---
  drivers/gpu/drm/i915/i915_guc_submission.c | 94
+-
  1 file changed, 53 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 45b33f8..1833bfd 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -174,31 +174,59 @@ static int host2guc_sample_forcewake(struct
intel_guc *guc,
   * client object which contains the page being used for the doorbell
   */

-static void guc_init_doorbell(struct intel_guc *guc,
-  struct i915_guc_client *client)
+static int guc_update_doorbell_id(struct intel_guc *guc,
+  struct i915_guc_client *client,
+  u16 new_id)
  {
+struct sg_table *sg = guc->ctx_pool_obj->pages;
+void *doorbell_bitmap = guc->doorbell_bitmap;
  struct guc_doorbell_info *doorbell;
+struct guc_context_desc desc;
+size_t len;

  doorbell = client->client_base + client->doorbell_offset;

-doorbell->db_status = GUC_DOORBELL_ENABLED;
+if (client->doorbell_id != GUC_INVALID_DOORBELL_ID &&
+test_bit(client->doorbell_id, doorbell_bitmap)) {
+/* Deactivate the old doorbell */
+doorbell->db_status = GUC_DOORBELL_DISABLED;
+(void)host2guc_release_doorbell(guc, client);
+__clear_bit(client->doorbell_id, doorbell_bitmap);
+}
+
+/* Update the GuC's idea of the doorbell ID */
+len = sg_pcopy_to_buffer(sg->sgl, sg->nents, , sizeof(desc),
+ sizeof(desc) * client->ctx_index);
+if (len != sizeof(desc))
+return -EFAULT;
+desc.db_id = new_id;
+len = sg_pcopy_from_buffer(sg->sgl, sg->nents, , sizeof(desc),
+ sizeof(desc) * client->ctx_index);
+if (len != sizeof(desc))
+return -EFAULT;
+
+client->doorbell_id = new_id;
+if (new_id == GUC_INVALID_DOORBELL_ID)
+return 0;
+
+/* Activate the new doorbell */
+__set_bit(new_id, doorbell_bitmap);


Is this the same bit as in assign_doorbell so redundant?


It is the same bit, and yes, it will be redundant during the initial 
setup, but when we come to *re*assign the association between a client 
and a doorbell (in the next patch) then it won't be.


We could also choose to have assign_doorbell() NOT update the map, so 
then this would be the only place where the bitmap gets updated. I'd 
have to rename it though, as it would no longer be assigning anything!


.Dave.


  doorbell->cookie = 0;
+doorbell->db_status = GUC_DOORBELL_ENABLED;
+return host2guc_allocate_doorbell(guc, client);
+}
+
+static int guc_init_doorbell(struct intel_guc *guc,
+  struct i915_guc_client *client,
+  uint16_t db_id)
+{
+return guc_update_doorbell_id(guc, client, db_id);
  }

  static void guc_disable_doorbell(struct 

[Intel-gfx] [PATCH RESEND 3/7] drm/i915/dsi: add skip functions for spi and pmic elements

[Jani Nikula]

In sequence block v3 these are gracefully skipped anyway, but add the
functions so we can have some debug breadcrumbs.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index 3e840a526f53..7dd850760c4d 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -344,6 +344,20 @@ static const u8 *mipi_exec_i2c(struct intel_dsi 
*intel_dsi, const u8 *data)
return data + *(data + 6) + 7;
 }
 
+static const u8 *mipi_exec_spi(struct intel_dsi *intel_dsi, const u8 *data)
+{
+   DRM_DEBUG_KMS("Skipping SPI element execution\n");
+
+   return data + *(data + 5) + 6;
+}
+
+static const u8 *mipi_exec_pmic(struct intel_dsi *intel_dsi, const u8 *data)
+{
+   DRM_DEBUG_KMS("Skipping PMIC element execution\n");
+
+   return data + 14;
+}
+
 typedef const u8 * (*fn_mipi_elem_exec)(struct intel_dsi *intel_dsi,
const u8 *data);
 static const fn_mipi_elem_exec exec_elem[] = {
@@ -351,6 +365,8 @@ static const fn_mipi_elem_exec exec_elem[] = {
[MIPI_SEQ_ELEM_DELAY] = mipi_exec_delay,
[MIPI_SEQ_ELEM_GPIO] = mipi_exec_gpio,
[MIPI_SEQ_ELEM_I2C] = mipi_exec_i2c,
+   [MIPI_SEQ_ELEM_SPI] = mipi_exec_spi,
+   [MIPI_SEQ_ELEM_PMIC] = mipi_exec_pmic,
 };
 
 /*
-- 
2.1.4

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

[Intel-gfx] [PATCH RESEND 6/7] drm/i915/bios: log about presence of DSI sequences we do not run

[Jani Nikula]

Leave behind some debugging clues in case some panels don't work
properly.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_bios.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index da5ed4a850b9..e2f47ff156a7 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -996,6 +996,10 @@ parse_mipi_sequence(struct drm_i915_private *dev_priv,
goto err;
}
 
+   /* Log about presence of sequences we won't run. */
+   if (seq_id == MIPI_SEQ_TEAR_ON || seq_id == MIPI_SEQ_TEAR_OFF)
+   DRM_DEBUG_KMS("Unsupported sequence %u\n", seq_id);
+
dev_priv->vbt.dsi.sequence[seq_id] = data + index;
 
if (sequence->version >= 3)
-- 
2.1.4

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

[Intel-gfx] [PATCH RESEND 7/7] drm/i915/dsi: double check element parsing against size if present

[Jani Nikula]

Be a little paranoid in case the specs change or something.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index d078c5765014..30fcb02fce9b 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -441,7 +441,15 @@ static void generic_exec_sequence(struct drm_panel *panel, 
enum mipi_seq seq_id)
operation_size = *data++;
 
if (mipi_elem_exec) {
+   const u8 *next = data + operation_size;
+
data = mipi_elem_exec(intel_dsi, data);
+
+   /* Consistency check if we have size. */
+   if (operation_size && data != next) {
+   DRM_ERROR("Inconsistent operation size\n");
+   return;
+   }
} else if (operation_size) {
/* We have size, skip. */
DRM_DEBUG_KMS("Unsupported MIPI operation byte %u\n",
-- 
2.1.4

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

[Intel-gfx] [PATCH RESEND 5/7] drm/i915/dsi: run backlight on/off sequences in panel enable/disable hooks

[Jani Nikula]

Based on the documentation alone, it's anyone's guess when exactly we
should be running these sequences. Add them where it feels logical. The
drm panel hooks don't currently offer us more granularity anyway.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index e0337a82a6b4..d078c5765014 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -476,12 +476,14 @@ static int vbt_panel_unprepare(struct drm_panel *panel)
 static int vbt_panel_enable(struct drm_panel *panel)
 {
generic_exec_sequence(panel, MIPI_SEQ_DISPLAY_ON);
+   generic_exec_sequence(panel, MIPI_SEQ_BACKLIGHT_ON);
 
return 0;
 }
 
 static int vbt_panel_disable(struct drm_panel *panel)
 {
+   generic_exec_sequence(panel, MIPI_SEQ_BACKLIGHT_OFF);
generic_exec_sequence(panel, MIPI_SEQ_DISPLAY_OFF);
 
return 0;
-- 
2.1.4

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

[Intel-gfx] [PATCH RESEND 4/7] drm/i915/dsi: run power on/off sequences in panel prepare/unprepare hooks

[Jani Nikula]

Based on the documentation alone, it's anyone's guess when exactly we
should be running these sequences. Add them where it feels logical. The
drm panel hooks don't currently offer us more granularity anyway.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index 7dd850760c4d..e0337a82a6b4 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -459,6 +459,7 @@ static void generic_exec_sequence(struct drm_panel *panel, 
enum mipi_seq seq_id)
 static int vbt_panel_prepare(struct drm_panel *panel)
 {
generic_exec_sequence(panel, MIPI_SEQ_ASSERT_RESET);
+   generic_exec_sequence(panel, MIPI_SEQ_POWER_ON);
generic_exec_sequence(panel, MIPI_SEQ_INIT_OTP);
 
return 0;
@@ -466,6 +467,7 @@ static int vbt_panel_prepare(struct drm_panel *panel)
 
 static int vbt_panel_unprepare(struct drm_panel *panel)
 {
+   generic_exec_sequence(panel, MIPI_SEQ_POWER_OFF);
generic_exec_sequence(panel, MIPI_SEQ_DEASSERT_RESET);
 
return 0;
-- 
2.1.4

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

Re: [Intel-gfx] [PATCH v2 6/6] drm/i915/guc: (re)initialise doorbell h/w when enabling GuC submission

[Tvrtko Ursulin]

On 10/06/16 17:51, Dave Gordon wrote:

During a hibernate/resume cycle, the whole system is reset, including
the GuC and the doorbell hardware. Then the system is booted up, drivers
are loaded, etc -- the GuC firmware may be loaded and set running at
this point. But then, the booted kernel is replaced by the hibernated
image, and this resumed kernel will also try to reload the GuC firmware
(which will fail). To recover, we reset the GuC and try again (which
should work). But this GuC reset doesn't also reset the doorbell
hardware, so it can be left in a state inconsistent with that assumed
by the driver and/or the newly-loaded GuC firmware.

It would be better if the GuC reset also cleared all doorbell state,
but that's not how the hardware currently works; also, the driver cannot
directly reprogram the doorbell hardware (only the GuC can do that).

So this patch cycles through all doorbells, assigning and releasing each
in turn, so that all the doorbell hardware is left in a consistent
state, no matter how it was programmed by the previously-running kernel
and/or GuC firmware.

v2: don't use kmap_atomic() now that client page 0 is kept mapped.

Signed-off-by: Dave Gordon 
---
  drivers/gpu/drm/i915/i915_guc_submission.c | 44 +-
  1 file changed, 43 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 1833bfd..120d2e8 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -694,6 +694,48 @@ static void guc_client_free(struct drm_device *dev,
kfree(client);
  }

+/*
+ * Borrow the first client to set up & tear down every doorbell
+ * in turn, to ensure that all doorbell h/w is (re)initialised.
+ */
+static void guc_init_doorbell_hw(struct intel_guc *guc)
+{
+   struct drm_i915_private *dev_priv = guc_to_i915(guc);
+   struct i915_guc_client *client = guc->execbuf_client;
+   uint16_t db_id, i;
+   int err;
+
+   db_id = client->doorbell_id;
+
+   for (i = 0; i < GUC_MAX_DOORBELLS; ++i) {
+   i915_reg_t drbreg = GEN8_DRBREGL(i);
+   u32 value = I915_READ(drbreg);
+
+   err = guc_update_doorbell_id(guc, client, i);
+
+   /* Report update failure or unexpectedly active doorbell */
+   if (err || (i != db_id && (value & GUC_DOORBELL_ENABLED)))
+   DRM_DEBUG_DRIVER("Doorbell %d (reg 0x%x) was 0x%x, err 
%d\n",
+ i, drbreg.reg, value, err);
+   }
+
+   /* Restore to original value */
+   err = guc_update_doorbell_id(guc, client, db_id);
+   if (err)
+   DRM_ERROR("Failed to restore doorbell to %d, err %d\n",
+   db_id, err);
+
+   for (i = 0; i < GUC_MAX_DOORBELLS; ++i) {
+   i915_reg_t drbreg = GEN8_DRBREGL(i);
+   u32 value = I915_READ(drbreg);
+
+   if (i != db_id && (value & GUC_DOORBELL_ENABLED))
+   DRM_DEBUG_DRIVER("Doorbell %d (reg 0x%x) finally 
0x%x\n",
+ i, drbreg.reg, value);
+
+   }
+}
+
  /**
   * guc_client_alloc() - Allocate an i915_guc_client
   * @dev:  drm device
@@ -959,8 +1001,8 @@ int i915_guc_submission_enable(struct drm_device *dev)
}

guc->execbuf_client = client;
-
host2guc_sample_forcewake(guc, client);
+   guc_init_doorbell_hw(guc);

return 0;
  }



Reviewed-by: Tvrtko Ursulin 

Regards,

Tvrtko

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

[Intel-gfx] [PATCH RESEND 2/7] drm/i915/dsi: add debug logging to element execution

[Jani Nikula]

Just simple breadcrumbs for now. While at it, rename the i2c skip
function.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index 4d05f0bfaea3..3e840a526f53 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -126,6 +126,8 @@ static const u8 *mipi_exec_send_packet(struct intel_dsi 
*intel_dsi,
u16 len;
enum port port;
 
+   DRM_DEBUG_KMS("\n");
+
flags = *data++;
type = *data++;
 
@@ -199,6 +201,8 @@ static const u8 *mipi_exec_delay(struct intel_dsi 
*intel_dsi, const u8 *data)
 {
u32 delay = *((const u32 *) data);
 
+   DRM_DEBUG_KMS("\n");
+
usleep_range(delay, delay + 10);
data += 4;
 
@@ -307,6 +311,8 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
*intel_dsi, const u8 *data)
u8 gpio_source, gpio_index;
bool value;
 
+   DRM_DEBUG_KMS("\n");
+
if (dev_priv->vbt.dsi.seq_version >= 3)
data++;
 
@@ -331,8 +337,10 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
*intel_dsi, const u8 *data)
return data;
 }
 
-static const u8 *mipi_exec_i2c_skip(struct intel_dsi *intel_dsi, const u8 
*data)
+static const u8 *mipi_exec_i2c(struct intel_dsi *intel_dsi, const u8 *data)
 {
+   DRM_DEBUG_KMS("Skipping I2C element execution\n");
+
return data + *(data + 6) + 7;
 }
 
@@ -342,7 +350,7 @@ static const fn_mipi_elem_exec exec_elem[] = {
[MIPI_SEQ_ELEM_SEND_PKT] = mipi_exec_send_packet,
[MIPI_SEQ_ELEM_DELAY] = mipi_exec_delay,
[MIPI_SEQ_ELEM_GPIO] = mipi_exec_gpio,
-   [MIPI_SEQ_ELEM_I2C] = mipi_exec_i2c_skip,
+   [MIPI_SEQ_ELEM_I2C] = mipi_exec_i2c,
 };
 
 /*
-- 
2.1.4

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

[Intel-gfx] [PATCH RESEND 1/7] drm/i915/dsi: don't debug log "missing" sequences

[Jani Nikula]

This is not interesting. They are not "missing", they are just not part
of the VBT sequences for the panel.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index f122484bedfc..4d05f0bfaea3 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -385,11 +385,8 @@ static void generic_exec_sequence(struct drm_panel *panel, 
enum mipi_seq seq_id)
return;
 
data = dev_priv->vbt.dsi.sequence[seq_id];
-   if (!data) {
-   DRM_DEBUG_KMS("MIPI sequence %d - %s not available\n",
- seq_id, sequence_name(seq_id));
+   if (!data)
return;
-   }
 
WARN_ON(*data != seq_id);
 
-- 
2.1.4

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