[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/scheduler: add gvt force-single-submission and notification for guc (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915/scheduler: add gvt force-single-submission and notification 
for guc (rev4)
URL   : https://patchwork.freedesktop.org/series/21972/
State : failure

== Summary ==

Series 21972v4 drm/i915/scheduler: add gvt force-single-submission and 
notification for guc
https://patchwork.freedesktop.org/api/1.0/series/21972/revisions/4/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
pass   -> FAIL   (fi-snb-2600) fdo#17
Test pm_rpm:
Subgroup basic-pci-d3-state:
pass   -> INCOMPLETE (fi-byt-j1900)
Subgroup basic-rte:
pass   -> INCOMPLETE (fi-bsw-n3050) fdo#100718

fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17
fdo#100718 https://bugs.freedesktop.org/show_bug.cgi?id=100718

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:431s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:426s
fi-bsw-n3050 total:242  pass:207  dwarn:0   dfail:0   fail:0   skip:34 
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:510s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:564s
fi-byt-j1900 total:241  pass:217  dwarn:0   dfail:0   fail:0   skip:23 
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:481s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:409s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:413s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:425s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:499s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:462s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:457s
fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:561s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:451s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:568s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:465s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:497s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:441s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:531s
fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:1   skip:29  
time:397s

1b757084743a73fa672e92b4e5cf00a291667dfc drm-tip: 2017y-04m-19d-12h-50m-15s UTC 
integration manifest
03cb65f drm/i915: refactor gvt force-single-submission

== Logs ==

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

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/scheduler: add gvt force-single-submission and notification for guc (rev4)

[Saarinen, Jani]

Hi, 
> == Series Details ==
> 
> Series: drm/i915/scheduler: add gvt force-single-submission and notification
> for guc (rev4)
> URL   : https://patchwork.freedesktop.org/series/21972/
> State : failure
> 
> == Summary ==
> 
> Series 21972v4 drm/i915/scheduler: add gvt force-single-submission and
> notification for guc
> https://patchwork.freedesktop.org/api/1.0/series/21972/revisions/4/mbox/
> 
> Test gem_exec_flush:
> Subgroup basic-batch-kernel-default-uc:
> pass   -> FAIL   (fi-snb-2600) fdo#17
> Test gem_exec_suspend:
> Subgroup basic-s4-devices:
> pass   -> DMESG-WARN (fi-kbl-7560u) fdo#100125
> Test kms_pipe_crc_basic:
> Subgroup suspend-read-crc-pipe-c:
> pass   -> FAIL   (fi-skl-6700k)
Seems to match https://bugs.freedesktop.org/show_bug.cgi?id=100367
Re-running and marking known for CI. 

> Test pm_rpm:
> Subgroup basic-rte:
> pass   -> INCOMPLETE (fi-bsw-n3050) fdo#100718
> 
> fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17
> fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125
> fdo#100718 https://bugs.freedesktop.org/show_bug.cgi?id=100718
> 
> fi-skl-6700k total:278  pass:255  dwarn:4   dfail:0   fail:1   skip:18  
> time:457s
> 
> 1b757084743a73fa672e92b4e5cf00a291667dfc drm-tip: 2017y-04m-19d-12h-
> 50m-15s UTC integration manifest
> 4f12487 drm/i915: refactor gvt force-single-submission
> 
> == Logs ==
> 
> For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4521/


Jani Saarinen
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo


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

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/scheduler: add gvt force-single-submission and notification for guc (rev4)

[Dong, Chuanxiao]

> -Original Message-
> From: Saarinen, Jani
> Sent: Thursday, April 20, 2017 2:30 PM
> To: intel-gfx@lists.freedesktop.org; Dong, Chuanxiao
> 
> Subject: RE: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/scheduler: add gvt
> force-single-submission and notification for guc (rev4)
> 
> Hi,
> > == Series Details ==
> >
> > Series: drm/i915/scheduler: add gvt force-single-submission and
> > notification for guc (rev4)
> > URL   : https://patchwork.freedesktop.org/series/21972/
> > State : failure
> >
> > == Summary ==
> >
> > Series 21972v4 drm/i915/scheduler: add gvt force-single-submission and
> > notification for guc
> > https://patchwork.freedesktop.org/api/1.0/series/21972/revisions/4/mbo
> > x/
> >
> > Test gem_exec_flush:
> > Subgroup basic-batch-kernel-default-uc:
> > pass   -> FAIL   (fi-snb-2600) fdo#17
> > Test gem_exec_suspend:
> > Subgroup basic-s4-devices:
> > pass   -> DMESG-WARN (fi-kbl-7560u) fdo#100125
> > Test kms_pipe_crc_basic:
> > Subgroup suspend-read-crc-pipe-c:
> > pass   -> FAIL   (fi-skl-6700k)
> Seems to match https://bugs.freedesktop.org/show_bug.cgi?id=100367
> Re-running and marking known for CI.

I see. Thanks Jani. :)

Thanks
Chuanxiao

> 
> > Test pm_rpm:
> > Subgroup basic-rte:
> > pass   -> INCOMPLETE (fi-bsw-n3050) fdo#100718
> >
> > fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17
> > fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125
> > fdo#100718 https://bugs.freedesktop.org/show_bug.cgi?id=100718
> >
> > fi-skl-6700k total:278  pass:255  dwarn:4   dfail:0   fail:1   skip:18
> time:457s
> >
> > 1b757084743a73fa672e92b4e5cf00a291667dfc drm-tip: 2017y-04m-19d-
> 12h-
> > 50m-15s UTC integration manifest
> > 4f12487 drm/i915: refactor gvt force-single-submission
> >
> > == Logs ==
> >
> > For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4521/
> 
> 
> Jani Saarinen
> Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
> 

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

Re: [Intel-gfx] [PATCH v4 2/9] drm/i915: Add plumbing for digital connector state, v2.

[Maarten Lankhorst]

On 19-04-17 17:48, Daniel Vetter wrote:
> On Wed, Apr 12, 2017 at 12:50:00PM +0200, Maarten Lankhorst wrote:
>> Some atomic properties are common between the various kinds of
>> connectors, for example a lot of them use panel fitting mode.
>> It makes sense to put a lot of it in a common place, so each
>> connector can use it while they're being converted.
>>
>> Implement the properties required for the connectors:
>> - scaling mode property
>> - force audio property
>> - broadcast rgb
>> - aspect ratio
>>
>> While at it, make clear that intel_digital_connector_atomic_get_property
>> is a hack that has to be removed when all connector properties
>> are converted to atomic.
>>
>> Changes since v1:
>> - Scaling mode and aspect ratio are partly handled in core now.
>>
>> Signed-off-by: Maarten Lankhorst 
>> ---
>>  drivers/gpu/drm/i915/intel_atomic.c  | 142 
>> +--
>>  drivers/gpu/drm/i915/intel_display.c |  14 +++-
>>  drivers/gpu/drm/i915/intel_dp.c  |   2 +-
>>  drivers/gpu/drm/i915/intel_drv.h |  27 ++-
>>  drivers/gpu/drm/i915/intel_dsi.c |   2 +-
>>  drivers/gpu/drm/i915/intel_dvo.c |   2 +-
>>  drivers/gpu/drm/i915/intel_lvds.c|   2 +-
>>  drivers/gpu/drm/i915/intel_panel.c   |   4 +-
>>  8 files changed, 180 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
>> b/drivers/gpu/drm/i915/intel_atomic.c
>> index 50fb1f76cc5f..eb72166675f0 100644
>> --- a/drivers/gpu/drm/i915/intel_atomic.c
>> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> Refactoring idea for the future: intel_atomic.c makes 0 sense, just makes
> sure we have lots of functionality spread all over imo. I think following
> the split-up model I've done in the drm core would be a lot better, with
> intel_connector/encoder/crtc/plane.c for the shared helper functions. And
> then maybe separate files for the per-platform stuff, e.g. i9xx_crtc.c,
> pch_crtc.c and so on.
>
>> @@ -36,7 +36,7 @@
>>  #include "intel_drv.h"
>>  
>>  /**
>> - * intel_connector_atomic_get_property - fetch connector property value
>> + * intel_connector_atomic_get_property - fetch legacy connector property 
>> value
>>   * @connector: connector to fetch property for
>>   * @state: state containing the property value
>>   * @property: property to look up
>> @@ -45,12 +45,14 @@
>>   * The DRM core does not store shadow copies of properties for
>>   * atomic-capable drivers.  This entrypoint is used to fetch
>>   * the current value of a driver-specific connector property.
>> + *
>> + * This is a intermediary solution until all connectors are
>> + * converted to support full atomic properties.
>>   */
>> -int
>> -intel_connector_atomic_get_property(struct drm_connector *connector,
>> -const struct drm_connector_state *state,
>> -struct drm_property *property,
>> -uint64_t *val)
>> +int intel_connector_atomic_get_property(struct drm_connector *connector,
>> +const struct drm_connector_state *state,
>> +struct drm_property *property,
>> +uint64_t *val)
>>  {
>>  int i;
>>  
>> @@ -73,7 +75,133 @@ intel_connector_atomic_get_property(struct drm_connector 
>> *connector,
>>  return -EINVAL;
>>  }
>>  
>> -/*
>> +/**
>> + * intel_digital_connector_atomic_get_property - hook for 
>> connector->atomic_get_property.
>> + * @connector: Connector to get the property for.
>> + * @state: Connector state to retrieve the property from.
>> + * @property: Property to retrieve.
>> + * @val: Return value for the property.
>> + *
>> + * Returns the atomic property value for a digital connector.
>> + */
>> +int intel_digital_connector_atomic_get_property(struct drm_connector 
>> *connector,
>> +const struct 
>> drm_connector_state *state,
>> +struct drm_property *property,
>> +uint64_t *val)
>> +{
>> +struct drm_device *dev = connector->dev;
>> +struct drm_i915_private *dev_priv = to_i915(dev);
>> +struct intel_digital_connector_state *intel_conn_state =
>> +to_intel_digital_connector_state(state);
>> +
>> +if (property == dev_priv->force_audio_property)
>> +*val = intel_conn_state->force_audio;
>> +else if (property == dev_priv->broadcast_rgb_property)
>> +*val = intel_conn_state->broadcast_rgb;
>> +else {
>> +DRM_DEBUG_ATOMIC("Unknown property %s\n", property->name);
>> +return -EINVAL;
>> +}
>> +
>> +return 0;
>> +}
>> +
>> +/**
>> + * intel_digital_connector_atomic_set_property - hook for 
>> connector->atomic_set_property.
>> + * @connector: Connector to set the property for.
>> + * @state: Connector state to set the property on.
>> + * @property: Property to set.
>> + * @va

[Intel-gfx] [RESEND][GIT PULL] GVT-g next fixes for 4.12

[Zhenyu Wang]

Hi,
 
Please pull gvt next fixes for 4.12.

(resend with subscribed mail address.)

Thanks.

--
The following changes since commit b35f34d1da4e77637869c8041a355da810f69fb6:

  drm/i915/gvt: control the scheduler by timeslice usage (2017-03-30 13:34:10 
+0800)

are available in the git repository at:

  https://github.com/01org/gvt-linux.git tags/gvt-next-fixes-2017-04-20

for you to fetch changes up to c821ee6d2bb4cfc9991bf285f53103cde9d3593a:

  drm/i915/gvt: fix a bounds check in ring_id_to_context_switch_event() 
(2017-04-18 17:50:05 +0800)


gvt-next-fixes-2017-04-20

- some code optimization from Changbin
- debug message cleanup after QoS merge
- misc fixes for display mmio init, reset vgpu warning, etc.


Changbin Du (4):
  drm/i915/gvt: Align render mmio list to cacheline
  drm/i915/gvt: remove redundant platform check for mocs load/restore
  drm/i915/gvt: remove redundant ring id check which cause significant CPU 
misprediction
  drm/i915/gvt: use directly assignment for structure copying

Dan Carpenter (1):
  drm/i915/gvt: fix a bounds check in ring_id_to_context_switch_event()

Pei Zhang (1):
  drm/i915/gvt: add mmio init for virtual display

Zhenyu Wang (3):
  drm/i915/gvt: cleanup some too chatty scheduler message
  drm/i915/gvt: remove some debug messages in scheduler timer handler
  drm/i915/gvt: Fix PTE write flush for taking runtime pm properly

 drivers/gpu/drm/i915/gvt/cmd_parser.c   |  8 +---
 drivers/gpu/drm/i915/gvt/display.c  | 29 -
 drivers/gpu/drm/i915/gvt/execlist.c |  8 +++-
 drivers/gpu/drm/i915/gvt/gtt.c  |  5 +
 drivers/gpu/drm/i915/gvt/render.c   | 10 ++
 drivers/gpu/drm/i915/gvt/sched_policy.c | 17 ++---
 drivers/gpu/drm/i915/gvt/scheduler.c|  5 +
 7 files changed, 42 insertions(+), 40 deletions(-)

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/scheduler: add gvt force-single-submission and notification for guc (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915/scheduler: add gvt force-single-submission and notification 
for guc (rev4)
URL   : https://patchwork.freedesktop.org/series/21972/
State : failure

== Summary ==

Series 21972v4 drm/i915/scheduler: add gvt force-single-submission and 
notification for guc
https://patchwork.freedesktop.org/api/1.0/series/21972/revisions/4/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
pass   -> FAIL   (fi-snb-2600) fdo#17
Test gem_exec_suspend:
Subgroup basic-s4-devices:
pass   -> DMESG-WARN (fi-kbl-7560u) fdo#100125
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-c:
pass   -> FAIL   (fi-skl-6700k)
Test pm_rpm:
Subgroup basic-rte:
pass   -> INCOMPLETE (fi-bsw-n3050) fdo#100718

fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17
fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125
fdo#100718 https://bugs.freedesktop.org/show_bug.cgi?id=100718

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:431s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:426s
fi-bsw-n3050 total:242  pass:207  dwarn:0   dfail:0   fail:0   skip:34 
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:519s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:564s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:491s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:482s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:409s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:407s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:423s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:500s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:470s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:458s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time:567s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:451s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:570s
fi-skl-6700k total:278  pass:255  dwarn:4   dfail:0   fail:1   skip:18  
time:457s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:496s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:429s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:528s
fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:1   skip:29  
time:402s

1b757084743a73fa672e92b4e5cf00a291667dfc drm-tip: 2017y-04m-19d-12h-50m-15s UTC 
integration manifest
4f12487 drm/i915: refactor gvt force-single-submission

== Logs ==

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

[Intel-gfx] [GIT PULL] GVT-g next fixes for 4.12

[Zhenyu Wang]

Hi,

Please pull gvt next fixes for 4.12.

Thanks

--
The following changes since commit b35f34d1da4e77637869c8041a355da810f69fb6:

  drm/i915/gvt: control the scheduler by timeslice usage (2017-03-30 13:34:10 
+0800)

are available in the git repository at:

  https://github.com/01org/gvt-linux.git tags/gvt-next-fixes-2017-04-20

for you to fetch changes up to c821ee6d2bb4cfc9991bf285f53103cde9d3593a:

  drm/i915/gvt: fix a bounds check in ring_id_to_context_switch_event() 
(2017-04-18 17:50:05 +0800)


gvt-next-fixes-2017-04-20

- some code optimization from Changbin
- debug message cleanup after QoS merge
- misc fixes for display mmio init, reset vgpu warning, etc.


Changbin Du (4):
  drm/i915/gvt: Align render mmio list to cacheline
  drm/i915/gvt: remove redundant platform check for mocs load/restore
  drm/i915/gvt: remove redundant ring id check which cause significant CPU 
misprediction
  drm/i915/gvt: use directly assignment for structure copying

Dan Carpenter (1):
  drm/i915/gvt: fix a bounds check in ring_id_to_context_switch_event()

Pei Zhang (1):
  drm/i915/gvt: add mmio init for virtual display

Zhenyu Wang (3):
  drm/i915/gvt: cleanup some too chatty scheduler message
  drm/i915/gvt: remove some debug messages in scheduler timer handler
  drm/i915/gvt: Fix PTE write flush for taking runtime pm properly

 drivers/gpu/drm/i915/gvt/cmd_parser.c   |  8 +---
 drivers/gpu/drm/i915/gvt/display.c  | 29 -
 drivers/gpu/drm/i915/gvt/execlist.c |  8 +++-
 drivers/gpu/drm/i915/gvt/gtt.c  |  5 +
 drivers/gpu/drm/i915/gvt/render.c   | 10 ++
 drivers/gpu/drm/i915/gvt/sched_policy.c | 17 ++---
 drivers/gpu/drm/i915/gvt/scheduler.c|  5 +
 7 files changed, 42 insertions(+), 40 deletions(-)


-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


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

[Intel-gfx] [PATCH 4/4] drm/i915/scheduler: add gvt notification for guc

[Chuanxiao Dong]

GVT request needs a manual mmio load/restore. Before GuC submit
a request, send notification to gvt for mmio loading. And after
the GuC finished this GVT request, notify gvt again for mmio
restore. This follows the usage when using execlists submission.

Cc: xiao.zh...@intel.com
Cc: kevin.t...@intel.com
Cc: joonas.lahti...@linux.intel.com
Cc: ch...@chris-wilson.co.uk
Signed-off-by: Chuanxiao Dong 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 862f4fd..2f3bb16 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -606,6 +606,8 @@ static void __i915_guc_submit(struct drm_i915_gem_request 
*rq)
unsigned long flags;
int b_ret;
 
+   intel_gvt_notify_context_status(rq, INTEL_CONTEXT_SCHEDULE_IN);
+
/* WA to flush out the pending GMADR writes to ring buffer. */
if (i915_vma_is_map_and_fenceable(rq->ring->vma))
POSTING_READ_FW(GUC_STATUS);
@@ -712,6 +714,8 @@ static void i915_guc_irq_handler(unsigned long data)
rq = port[0].request;
while (rq && i915_gem_request_completed(rq)) {
trace_i915_gem_request_out(rq);
+   intel_gvt_notify_context_status(rq,
+   INTEL_CONTEXT_SCHEDULE_OUT);
i915_gem_request_put(rq);
port[0].request = port[1].request;
port[1].request = NULL;
-- 
2.7.4

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

[Intel-gfx] [PATCH 2/4] drm/i915: refactor gvt context notification

[Chuanxiao Dong]

refactor gvt context notification to proper files

v1:
use context_status_change instead of execlists_context_status_change
for better understanding(ZhengXiao)
remove the comment as it is obvious and not friendly to the caller(Kevin)
fix indent issues(Joonas)
rename the context_status_change to intel_gvt_notify_context_status(Chris)
move intel_gvt_notify_context_status to intel_gvt.h(Joonas)

Cc: xiao.zh...@intel.com
Cc: kevin.t...@intel.com
Cc: joonas.lahti...@linux.intel.com
Cc: ch...@chris-wilson.co.uk
Signed-off-by: Chuanxiao Dong 
---
 drivers/gpu/drm/i915/intel_gvt.h | 12 
 drivers/gpu/drm/i915/intel_lrc.c | 21 +++--
 2 files changed, 15 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_gvt.h b/drivers/gpu/drm/i915/intel_gvt.h
index c0dcd66..813d0f8 100644
--- a/drivers/gpu/drm/i915/intel_gvt.h
+++ b/drivers/gpu/drm/i915/intel_gvt.h
@@ -38,6 +38,13 @@ intel_gvt_context_single_port_submit(const struct 
i915_gem_context *ctx)
 {
return i915_gem_context_force_single_submission(ctx);
 }
+static inline void
+intel_gvt_notify_context_status(struct drm_i915_gem_request *rq,
+   unsigned long status)
+{
+   atomic_notifier_call_chain(&rq->engine->context_status_notifier,
+  status, rq);
+}
 #else
 static inline int intel_gvt_init(struct drm_i915_private *dev_priv)
 {
@@ -51,6 +58,11 @@ intel_gvt_context_single_port_submit(const struct 
i915_gem_context *ctx)
 {
return false;
 }
+static inline void
+intel_gvt_notify_context_status(struct drm_i915_gem_request *rq,
+   unsigned long status)
+{
+}
 #endif
 
 #endif /* _INTEL_GVT_H_ */
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 61291e9..81f9a3b 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -295,21 +295,6 @@ uint64_t intel_lr_context_descriptor(struct 
i915_gem_context *ctx,
return ctx->engine[engine->id].lrc_desc;
 }
 
-static inline void
-execlists_context_status_change(struct drm_i915_gem_request *rq,
-   unsigned long status)
-{
-   /*
-* Only used when GVT-g is enabled now. When GVT-g is disabled,
-* The compiler should eliminate this function as dead-code.
-*/
-   if (!IS_ENABLED(CONFIG_DRM_I915_GVT))
-   return;
-
-   atomic_notifier_call_chain(&rq->engine->context_status_notifier,
-  status, rq);
-}
-
 static void
 execlists_update_context_pdps(struct i915_hw_ppgtt *ppgtt, u32 *reg_state)
 {
@@ -350,7 +335,7 @@ static void execlists_submit_ports(struct intel_engine_cs 
*engine)
 
GEM_BUG_ON(port[0].count > 1);
if (!port[0].count)
-   execlists_context_status_change(port[0].request,
+   intel_gvt_notify_context_status(port[0].request,
INTEL_CONTEXT_SCHEDULE_IN);
desc[0] = execlists_update_context(port[0].request);
GEM_DEBUG_EXEC(port[0].context_id = upper_32_bits(desc[0]));
@@ -358,7 +343,7 @@ static void execlists_submit_ports(struct intel_engine_cs 
*engine)
 
if (port[1].request) {
GEM_BUG_ON(port[1].count);
-   execlists_context_status_change(port[1].request,
+   intel_gvt_notify_context_status(port[1].request,
INTEL_CONTEXT_SCHEDULE_IN);
desc[1] = execlists_update_context(port[1].request);
GEM_DEBUG_EXEC(port[1].context_id = upper_32_bits(desc[1]));
@@ -560,7 +545,7 @@ static void intel_lrc_irq_handler(unsigned long data)
if (--port[0].count == 0) {
GEM_BUG_ON(status & GEN8_CTX_STATUS_PREEMPTED);

GEM_BUG_ON(!i915_gem_request_completed(port[0].request));
-   execlists_context_status_change(port[0].request,
+   intel_gvt_notify_context_status(port[0].request,

INTEL_CONTEXT_SCHEDULE_OUT);
 
trace_i915_gem_request_out(port[0].request);
-- 
2.7.4

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

[Intel-gfx] [PATCH 3/4] drm/i915/scheduler: add gvt force-single-submission for guc

[Chuanxiao Dong]

GVT needs single submission and cannot allow merge. So when GuC submitting
a GVT request, the next one should be submitted to guc later until the
previous one is completed. This is following the usage when using execlist
mode submission.

Cc: ch...@chris-wilson.co.uk
Signed-off-by: Chuanxiao Dong 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 1642fff..862f4fd 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -668,10 +668,14 @@ static bool i915_guc_dequeue(struct intel_engine_cs 
*engine)
struct drm_i915_gem_request *rq =
rb_entry(rb, typeof(*rq), priotree.node);
 
-   if (last && rq->ctx != last->ctx) {
+   if (last && !i915_gem_context_can_merge(last->ctx, rq->ctx)) {
if (port != engine->execlist_port)
break;
 
+   if (intel_gvt_context_single_port_submit(last->ctx) ||
+   intel_gvt_context_single_port_submit(rq->ctx))
+   break;
+
i915_gem_request_assign(&port->request, last);
nested_enable_signaling(last);
port++;
-- 
2.7.4

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

[Intel-gfx] [PATCH 1/4] drm/i915: refactor gvt force-single-submission

[Chuanxiao Dong]

refactor gvt force-single-submission to proper files

v1:
make force-single-submission specific to gvt (Chris)
keep the original code implementation (Chris)

Cc: ch...@chris-wilson.co.uk
Signed-off-by: Chuanxiao Dong 
---
 drivers/gpu/drm/i915/i915_gem_context.h | 13 +
 drivers/gpu/drm/i915/intel_gvt.h| 11 +++
 drivers/gpu/drm/i915/intel_lrc.c| 25 -
 3 files changed, 28 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_context.h 
b/drivers/gpu/drm/i915/i915_gem_context.h
index 4af2ab94..2c3afec 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/i915_gem_context.h
@@ -246,6 +246,19 @@ static inline bool i915_gem_context_is_kernel(struct 
i915_gem_context *ctx)
return !ctx->file_priv;
 }
 
+static inline bool
+i915_gem_context_can_merge(const struct i915_gem_context *prev,
+   const struct i915_gem_context *next)
+{
+   if (prev != next)
+   return false;
+
+   if (i915_gem_context_force_single_submission(prev))
+   return false;
+
+   return true;
+}
+
 /* i915_gem_context.c */
 int __must_check i915_gem_context_init(struct drm_i915_private *dev_priv);
 void i915_gem_context_lost(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_gvt.h b/drivers/gpu/drm/i915/intel_gvt.h
index 25df2d6..c0dcd66 100644
--- a/drivers/gpu/drm/i915/intel_gvt.h
+++ b/drivers/gpu/drm/i915/intel_gvt.h
@@ -32,6 +32,12 @@ void intel_gvt_cleanup(struct drm_i915_private *dev_priv);
 int intel_gvt_init_device(struct drm_i915_private *dev_priv);
 void intel_gvt_clean_device(struct drm_i915_private *dev_priv);
 int intel_gvt_init_host(void);
+
+static inline bool
+intel_gvt_context_single_port_submit(const struct i915_gem_context *ctx)
+{
+   return i915_gem_context_force_single_submission(ctx);
+}
 #else
 static inline int intel_gvt_init(struct drm_i915_private *dev_priv)
 {
@@ -40,6 +46,11 @@ static inline int intel_gvt_init(struct drm_i915_private 
*dev_priv)
 static inline void intel_gvt_cleanup(struct drm_i915_private *dev_priv)
 {
 }
+static inline bool
+intel_gvt_context_single_port_submit(const struct i915_gem_context *ctx)
+{
+   return false;
+}
 #endif
 
 #endif /* _INTEL_GVT_H_ */
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 0dc1cc4..61291e9 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -377,24 +377,6 @@ static void execlists_submit_ports(struct intel_engine_cs 
*engine)
writel(lower_32_bits(desc[0]), elsp);
 }
 
-static bool ctx_single_port_submission(const struct i915_gem_context *ctx)
-{
-   return (IS_ENABLED(CONFIG_DRM_I915_GVT) &&
-   i915_gem_context_force_single_submission(ctx));
-}
-
-static bool can_merge_ctx(const struct i915_gem_context *prev,
- const struct i915_gem_context *next)
-{
-   if (prev != next)
-   return false;
-
-   if (ctx_single_port_submission(prev))
-   return false;
-
-   return true;
-}
-
 static void execlists_dequeue(struct intel_engine_cs *engine)
 {
struct drm_i915_gem_request *last;
@@ -450,7 +432,8 @@ static void execlists_dequeue(struct intel_engine_cs 
*engine)
 * request, and so we never need to tell the hardware about
 * the first.
 */
-   if (last && !can_merge_ctx(cursor->ctx, last->ctx)) {
+   if (last &&
+   !i915_gem_context_can_merge(last->ctx, cursor->ctx)) {
/* If we are on the second port and cannot combine
 * this request with the last, then we are done.
 */
@@ -463,8 +446,8 @@ static void execlists_dequeue(struct intel_engine_cs 
*engine)
 * context (even though a different request) to
 * the second port.
 */
-   if (ctx_single_port_submission(last->ctx) ||
-   ctx_single_port_submission(cursor->ctx))
+   if (intel_gvt_context_single_port_submit(last->ctx) ||
+   intel_gvt_context_single_port_submit(cursor->ctx))
break;
 
GEM_BUG_ON(last->ctx == cursor->ctx);
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH v6 18/20] drm/i915: Watchdog timeout: DRM kernel interface to set the timeout

[Michel Thierry]

On 18/04/17 13:23, Michel Thierry wrote:

Final enablement patch for GPU hang detection using watchdog timeout.
Using the gem_context_setparam ioctl, users can specify the desired
timeout value in microseconds, and the driver will do the conversion to
'timestamps'.

The recommended default watchdog threshold for video engines is 6 us,
since this has been _empirically determined_ to be a good compromise for
low-latency requirements and low rate of false positives. The default
register value is ~106000us and the theoretical max value (all 1s) is
353 seconds.

Note, UABI engine ids and i915 engine ids are different, and this patch
uses the i915 ones. Some kind of mapping table [1] is required if we
decide to use the UABI engine ids.

[1] 
http://patchwork.freedesktop.org/patch/msgid/20170329135831.30254-2-ch...@chris-wilson.co.uk

v2: Fixed get api to return values in microseconds. Threshold updated to
be per context engine. Check for u32 overflow. Capture ctx threshold
value in error state.

v3: Add a way to get array size, short-cut to disable all thresholds,
return EFAULT / EINVAL as needed. Move the capture of the threshold
value in the error state into a new patch. BXT has a different
timestamp base (because why not?).

Signed-off-by: Tomas Elf 
Signed-off-by: Arun Siluvery 
Signed-off-by: Michel Thierry 
---
 drivers/gpu/drm/i915/i915_drv.h |  29 +
 drivers/gpu/drm/i915/i915_gem_context.c | 102 
 drivers/gpu/drm/i915/intel_lrc.c|   5 +-
 include/uapi/drm/i915_drm.h |   1 +
 4 files changed, 135 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 203f2112dd18..f65a236fddef 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3574,6 +3574,35 @@ i915_gem_context_lookup_timeline(struct i915_gem_context 
*ctx,
return &vm->timeline.engine[engine->id];
 }

+/*
+ * BDW & SKL+ Timestamp timer resolution = 0.080 uSec,
+ * or 1250 counts per second, or ~12 counts per microsecond.
+ *
+ * But Broxton Timestamp timer resolution is different, 0.052 uSec,
+ * or 1920 counts per second, or ~19 counts per microsecond.
+ */
+#define SKL_TIMESTAMP_CNTS_PER_USEC 12
+#define BXT_TIMESTAMP_CNTS_PER_USEC 19
+#define TIMESTAMP_CNTS_PER_USEC(dev_priv) (IS_BROXTON(dev_priv) ? \
+  BXT_TIMESTAMP_CNTS_PER_USEC : \
+  SKL_TIMESTAMP_CNTS_PER_USEC)
+static inline u32
+watchdog_to_us(struct drm_i915_private *dev_priv, u32 value_in_clock_counts)
+{
+   return value_in_clock_counts / TIMESTAMP_CNTS_PER_USEC(dev_priv);
+}
+
+static inline u32
+watchdog_to_clock_counts(struct drm_i915_private *dev_priv, u64 value_in_us)
+{
+   u64 threshold = value_in_us * TIMESTAMP_CNTS_PER_USEC(dev_priv);
+
+   if (overflows_type(threshold, u32))
+   return -EINVAL;
+
+   return threshold;
+}
+
 int i915_perf_open_ioctl(struct drm_device *dev, void *data,
 struct drm_file *file);

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index edbed85a1c88..85a6467a25a6 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -422,6 +422,102 @@ i915_gem_context_create_gvt(struct drm_device *dev)
return ctx;
 }

+/* Return the timer count threshold in microseconds. */
+int i915_gem_context_get_watchdog(struct i915_gem_context *ctx,
+ struct drm_i915_gem_context_param *args)
+{
+   struct drm_i915_private *dev_priv = ctx->i915;
+   struct intel_engine_cs *engine;
+   enum intel_engine_id id;
+   u32 threshold_in_us[I915_NUM_ENGINES];
+
+   if (args->size == 0)
+   goto out;
+
+   if (args->size < sizeof(threshold_in_us))
+   return -EFAULT;
+
+   if (!dev_priv->engine[VCS]->emit_start_watchdog)
+   return -ENODEV;
+
+   for_each_engine(engine, dev_priv, id) {
+   struct intel_context *ce = &ctx->engine[id];
+
+   threshold_in_us[id] = watchdog_to_us(dev_priv,
+ce->watchdog_threshold);
+   }
+
+   mutex_unlock(&dev_priv->drm.struct_mutex);
+   if (__copy_to_user(u64_to_user_ptr(args->value),
+  &threshold_in_us,
+  sizeof(threshold_in_us))) {
+   mutex_lock(&dev_priv->drm.struct_mutex);
+   return -EFAULT;
+   }
+   mutex_lock(&dev_priv->drm.struct_mutex);
+
+out:
+   args->size = sizeof(threshold_in_us);
+
+   return 0;
+}
+
+/*
+ * Based on time out value in microseconds (us) calculate
+ * timer count thresholds needed based on core frequency.
+ * Watchdog can be disabled by setting it to 0.
+ */
+int i915_gem_context_set_watchdog(struct i915_gem_context *ctx,
+

Re: [Intel-gfx] [PATCH v2] dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro

[Laura Abbott]

On 04/19/2017 12:36 PM, Logan Gunthorpe wrote:

Seeing the kunmap_atomic dma_buf_ops share the same name with a macro
in highmem.h, the former can be aliased if any dma-buf user includes
that header.

I'm personally trying to include highmem.h inside scatterlist.h and this
breaks the dma-buf code proper.

Christoph Hellwig suggested [1] renaming it and pushing this patch ASAP.

To maintain consistency I've renamed all four of kmap* and kunmap* to be
map* and unmap*. (Even though only kmap_atomic presently conflicts.)

[1] https://www.spinics.net/lists/target-devel/msg15070.html

Signed-off-by: Logan Gunthorpe 
Reviewed-by: Sinclair Yeh 
---

Changes since v1:

- Added the missing tegra driver (noticed by kbuild robot)
- Rebased off of drm-intel-next to get the i915 selftest that is new
- Fixed nits Sinclair pointed out.

  drivers/dma-buf/dma-buf.c  | 16 
  drivers/gpu/drm/armada/armada_gem.c|  8 
  drivers/gpu/drm/drm_prime.c|  8 
  drivers/gpu/drm/i915/i915_gem_dmabuf.c |  8 
  drivers/gpu/drm/i915/selftests/mock_dmabuf.c   |  8 
  drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c  |  8 
  drivers/gpu/drm/tegra/gem.c|  8 
  drivers/gpu/drm/udl/udl_dmabuf.c   |  8 
  drivers/gpu/drm/vmwgfx/vmwgfx_prime.c  |  8 
  drivers/media/v4l2-core/videobuf2-dma-contig.c |  4 ++--
  drivers/media/v4l2-core/videobuf2-dma-sg.c |  4 ++--
  drivers/media/v4l2-core/videobuf2-vmalloc.c|  4 ++--
  drivers/staging/android/ion/ion.c  |  8 
  include/linux/dma-buf.h| 22 +++---
  14 files changed, 61 insertions(+), 61 deletions(-)



For Ion,

Acked-by: Laura Abbott 

I did some major Ion refactoring but I don't think this
will conflict.

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

Re: [Intel-gfx] [PATCH v6 14/20] drm/i915/guc: Add support for reset engine using GuC commands

[Michel Thierry]

On 19/04/17 03:27, Chris Wilson wrote:

On Tue, Apr 18, 2017 at 01:23:29PM -0700, Michel Thierry wrote:

This patch adds per engine reset and recovery (TDR) support when GuC is
used to submit workloads to GPU.

In the case of i915 directly submission to ELSP, driver manages hang
detection, recovery and resubmission. With GuC submission these tasks
are shared between driver and GuC. i915 is still responsible for detecting
a hang, and when it does it only requests GuC to reset that Engine. GuC
internally manages acquiring forcewake and idling the engine before actually
resetting it.

Once the reset is successful, i915 takes over again and handles resubmission.
The scheduler in i915 knows which requests are pending so after resetting
a engine, pending workloads/requests are resubmitted again.

v2: s/i915_guc_request_engine_reset/i915_guc_reset_engine/ to match the
non-guc funtion names.

Signed-off-by: Arun Siluvery 
Signed-off-by: Jeff McGee 
Signed-off-by: Michel Thierry 
---
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 7df278fe492e..6295760098a1 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1176,14 +1176,15 @@ static int gen8_init_common_ring(struct intel_engine_cs 
*engine)

/* After a GPU reset, we may have requests to replay */
clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
-   if (!i915.enable_guc_submission && !execlists_elsp_idle(engine)) {
+   if (!execlists_elsp_idle(engine)) {
DRM_DEBUG_DRIVER("Restarting %s from requests [0x%x, 0x%x]\n",
 engine->name,
 port_seqno(&engine->execlist_port[0]),
 port_seqno(&engine->execlist_port[1]));
engine->execlist_port[0].count = 0;
engine->execlist_port[1].count = 0;
-   execlists_submit_ports(engine);
+   if (!dev_priv->guc.execbuf_client)
+   execlists_submit_ports(engine);


Not sure what you were intending to do here as this only resets the
submission count -- which is not used by guc dequeue. Some merit in the
making the code look similar, certainly adds the dbg message but I think
it is unrelated to the rest of the patch.


Yes, it only keeps the same debug message (originally added to check it 
was taking the right path). I can remove if you think it doesn't provide 
anything useful.

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

Re: [Intel-gfx] [PATCH 02/27] drm/i915: Mark CPU cache as dirty on every transition for CPU writes

[Dongwon Kim]

Chris,

I am sorry that I didn't tell you about GPU that
I am working on. It is GEN9LP. Our target is APL-I.
So no LLC is available. 

On Wed, Apr 19, 2017 at 07:26:29PM +0100, Chris Wilson wrote:
> On Wed, Apr 19, 2017 at 11:13:17AM -0700, Dongwon Kim wrote:
> > Chris,
> > 
> > Just to make sure, you want to just remove write_domain check from 
> > if statement before clflush in execbuffer_move_to_gpu. Am I right?
> > I will try both (cache_dirty only vs cache_dirty & !cache_coherent)
> > and get back to you shortly. 
> 
> Yes, I just don't have a single bit for cache_coherent yet, so you
> might as well let that call i915_gem_object_clflush().
> -Chris
> 
> -- 
> Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 02/27] drm/i915: Mark CPU cache as dirty on every transition for CPU writes

[Dongwon Kim]

Chris,

I think my assumption was not correct. I took out write_domain
check but it is still failing. However, here are couple of
observation points. I did some experiments.. One of them is 
to take out even cache_dirty check from eb_move_to_gpu. 
With this, all sample tests were passing but as you might 
expect, tests were running so slow, which explains how much 
clflush cost.

Then, I put cache_dirty check back into eb_move_to_gpu then
removed 'if (gpu_write_needs_clflush(obj))' from flush_write_domain
when write_domain is I915_GEM_DOMAIN_RENDER

@@ -753,6 +766,11 @@ flush_write_domain(struct drm_i915_gem_object *obj, unsigne
d int flush_domains)
+
+   case I915_GEM_DOMAIN_RENDER:
+   if (gpu_write_needs_clflush(obj)) <-- took out this line
+   obj->cache_dirty = true;
+   break;

to make cache_dirty is set all the time if write_domain is 
I915_GEM_DOMAIN_RENDER. And I saw some of failing tests were
now passing but this doesn't fix all of them.

I will try to revert back other changes in your patch as well.
Please let me know if there's any other thing you want me to
try to find a clue.

On Wed, Apr 19, 2017 at 07:26:29PM +0100, Chris Wilson wrote:
> On Wed, Apr 19, 2017 at 11:13:17AM -0700, Dongwon Kim wrote:
> > Chris,
> > 
> > Just to make sure, you want to just remove write_domain check from 
> > if statement before clflush in execbuffer_move_to_gpu. Am I right?
> > I will try both (cache_dirty only vs cache_dirty & !cache_coherent)
> > and get back to you shortly. 
> 
> Yes, I just don't have a single bit for cache_coherent yet, so you
> might as well let that call i915_gem_object_clflush().
> -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 v7 1/2] ACPI / bus: Introduce a list of ids for "always present" devices

[Rafael J. Wysocki]

On Wed, Apr 19, 2017 at 2:04 PM, Hans de Goede  wrote:
> Several Bay / Cherry Trail devices (all of which ship with Windows 10) hide
> the LPSS PWM controller in ACPI, typically the _STA method looks like this:
>
> Method (_STA, 0, NotSerialized)  // _STA: Status
> {
> If (OSID == One)
> {
> Return (Zero)
> }
>
> Return (0x0F)
> }
>
> Where OSID is some dark magic seen in all Cherry Trail ACPI tables making
> the machine behave differently depending on which OS it *thinks* it is
> booting, this gets set in a number of ways which we cannot control, on
> some newer machines it simple hardcoded to "One" aka win10.
>
> This causes the PWM controller to get hidden, which means Linux cannot
> control the backlight level on cht based tablets / laptops.
>
> Since loading the driver for this does no harm (the only in kernel user
> of it is the i915 driver, which will only uses it when it needs it), this
> commit makes acpi_bus_get_status() always set status to ACPI_STA_DEFAULT
> for the LPSS PWM device, fixing the lack of backlight control.
>
> Signed-off-by: Hans de Goede 
> ---
> Changes in v2:
> -Use pr_debug instead of ACPI_DEBUG_PRINT
> Changes in v3:
> -Un-inline acpi_set_device_status and do the always_present_device_ids
>  table check inside the un-inlined version of it
> Changes in v4:
> -Use dev_info instead of pr_debug
> -Not only check for ACPI HID but also for CPU (SoC) model so as to not
>  for devices present on other models then for which the quirk is intended and
>  to avoid enabling unrelated ACPI devices which happen to use the same HID
> Changes in v5:
> -Only do the dev_info once per device (acpi_set_device_status gets called
>  multiple times per device during boot)
> Changes in v6:
> -Allow specifying more then one CPU-model for a single HID
> -Not only match the HID but also the UID, like on Cherry Trail, on some Bay
>  Trail Windows 10 tablets we need to enable the PWM controller to get working
>  backlight even though _STA returns 0. The Bay Trail SoC has 2 PWM controllers
>  and we only need the first one. UID matching will allows adding an entry for
>  Bay Trail which only enables the first PWM controller
> Changes in v7:
> -Put the actual x86 specific matching code and table with always present
>  device HID + UID + CPU model entries in a new x86/x86_utils.c file which
>  provides an acpi_device_always_present() helper function on x86, on
>  non x86 a stub which always returns false is provided
> -Squash in the addition of the Bay Trail PWM entry in the table as it
>  is there for the same reasons as the Cherry Trail entry is there
> ---
>  drivers/acpi/Makefile|  1 +
>  drivers/acpi/bus.c   | 10 ++
>  drivers/acpi/x86/x86_utils.c | 85 
> 
>  include/acpi/acpi_bus.h  | 15 +---
>  4 files changed, 106 insertions(+), 5 deletions(-)
>  create mode 100644 drivers/acpi/x86/x86_utils.c
>
> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> index d78065c..f3940ac 100644
> --- a/drivers/acpi/Makefile
> +++ b/drivers/acpi/Makefile
> @@ -50,6 +50,7 @@ acpi-$(CONFIG_ACPI_REDUCED_HARDWARE_ONLY) += evged.o
>  acpi-y += sysfs.o
>  acpi-y += property.o
>  acpi-$(CONFIG_X86) += acpi_cmos_rtc.o
> +acpi-$(CONFIG_X86) += x86/x86_utils.o
>  acpi-$(CONFIG_DEBUG_FS)+= debugfs.o
>  acpi-$(CONFIG_ACPI_NUMA)   += numa.o
>  acpi-$(CONFIG_ACPI_PROCFS_POWER) += cm_sbs.o
> diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
> index 34fbe02..4d952cc 100644
> --- a/drivers/acpi/bus.c
> +++ b/drivers/acpi/bus.c
> @@ -132,6 +132,16 @@ int acpi_bus_get_status(struct acpi_device *device)
>  }
>  EXPORT_SYMBOL(acpi_bus_get_status);
>
> +void acpi_set_device_status(struct acpi_device *adev, u32 sta)
> +{
> +   u32 *status = (u32 *)&adev->status;
> +
> +   if (acpi_device_always_present(adev))
> +   *status = ACPI_STA_DEFAULT;
> +   else
> +   *status = sta;

*((u32 *)&adev->status) = acpi_device_always_present(adev) ?
ACPI_STA_DEFAULT : sta;

and I guess it could still be static inline?

But that said, evaluating _STA for the always present devices is
pointless (as Lukas noticed), so why not to modify
acpi_bus_get_status() to do something like:

if (acpi_device_always_present(adev)) {
acpi_set_device_status(adev, ACPI_STA_DEFAULT);
return 0;
}

upfront and modify the other path invoking acpi_set_device_status() accordingly.

And in that path, which I seem to have overlooked before, the
acpi_set_device_status() call is too early for invoking
acpi_device_always_present(adev), so the latter should be called
directly from acpi_add_single_object() like

acpi_init_device_object(device, handle, type, sta);
if (acpi_device_always_present(adev))
acpi_set_device_status(adev, ACPI_STA_DEFAULT);

Thanks,
Rafael
__

[Intel-gfx] ✓ Fi.CI.BAT: success for dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro (rev2)

[Patchwork]

== Series Details ==

Series: dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro 
(rev2)
URL   : https://patchwork.freedesktop.org/series/23207/
State : success

== Summary ==

Series 23207v2 dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic 
macro
https://patchwork.freedesktop.org/api/1.0/series/23207/revisions/2/mbox/

Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass   -> DMESG-WARN (fi-byt-j1900) fdo#100652

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:435s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:424s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:579s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:504s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:544s
fi-byt-j1900 total:278  pass:253  dwarn:1   dfail:0   fail:0   skip:24  
time:486s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:483s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:410s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:406s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:423s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:488s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:466s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:461s
fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:568s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:445s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:573s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:462s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:487s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:429s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:535s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:403s

1b757084743a73fa672e92b4e5cf00a291667dfc drm-tip: 2017y-04m-19d-12h-50m-15s UTC 
integration manifest
212adc7 dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro

== Logs ==

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

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

[Rafael J. Wysocki]

On Wed, Apr 19, 2017 at 6:17 PM, Lukas Wunner  wrote:
> On Wed, Apr 19, 2017 at 12:28:50PM +0200, Rafael J. Wysocki wrote:
>> On Wed, Apr 19, 2017 at 10:59 AM, Hans de Goede  wrote:
>> > On 18-04-17 15:34, Rafael J. Wysocki wrote:
>> >> On Tue, Apr 18, 2017 at 1:54 PM, Hans de Goede  
>> >> wrote:
>> >>>
>> >>> Several Cherry Trail devices (all of which ship with Windows 10) hide the
>> >>> LPSS PWM controller in ACPI, typically the _STA method looks like this:
>> >>>
>> >>> Method (_STA, 0, NotSerialized)  // _STA: Status
>> >>> {
>> >>> If (OSID == One)
>> >>> {
>> >>> Return (Zero)
>> >>> }
>> >>>
>> >>> Return (0x0F)
>> >>> }
>> >>>
>> >>> Where OSID is some dark magic seen in all Cherry Trail ACPI tables making
>> >>> the machine behave differently depending on which OS it *thinks* it is
>> >>> booting, this gets set in a number of ways which we cannot control, on
>> >>> some newer machines it simple hardcoded to "One" aka win10.
>> >>>
>> >>> This causes the PWM controller to get hidden, which means Linux cannot
>> >>> control the backlight level on cht based tablets / laptops.
>> >>>
>> >>> Since loading the driver for this does no harm (the only in kernel user
>> >>> of it is the i915 driver, which will only use it when it needs it), this
>> >>> commit makes acpi_bus_get_status() always set status to ACPI_STA_DEFAULT
>> >>> for the 80862288 device, fixing the lack of backlight control.
>> >>>
>> >>> Signed-off-by: Hans de Goede 
>> >>> ---
>> >>>  drivers/acpi/bus.c  | 65
>> >>> +
>> >>>  include/acpi/acpi_bus.h |  6 +
>> >>>  2 files changed, 66 insertions(+), 5 deletions(-)
>> >>>
>> >>> diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
>> >>> index 34fbe02..eb30630 100644
>> >>> --- a/drivers/acpi/bus.c
>> >>> +++ b/drivers/acpi/bus.c
>> >>> @@ -34,6 +34,8 @@
>> >>>  #include 
>> >>>  #include 
>> >>>  #ifdef CONFIG_X86
>> >>> +#include 
>> >>> +#include 
>> >>>  #include 
>> >>>  #endif
>> >>>  #include 
>> >>> @@ -132,6 +134,69 @@ int acpi_bus_get_status(struct acpi_device *device)
>> >>>  }
>> >>>  EXPORT_SYMBOL(acpi_bus_get_status);
>> >>>
>> >>> +#ifdef CONFIG_X86
>> >>> +/*
>> >>> + * Some ACPI devices are hidden (status == 0x0) in recent BIOS-es
>> >>> because
>> >>> + * some recent Windows drivers bind to one device but poke at multiple
>> >>> + * devices at the same time, so the others get hidden.
>> >>> + * We work around this by always reporting ACPI_STA_DEFAULT for these
>> >>> + * devices. Note this MUST only be done for devices where this is safe.
>> >>> + *
>> >>> + * This forcing of devices to be present is limited to specific CPU
>> >>> (SoC)
>> >>> + * models both to avoid potentially causing trouble on other models and
>> >>> + * because some HIDs are re-used on different SoCs for completely
>> >>> + * different devices.
>> >>> + */
>> >>> +struct always_present_device_id {
>> >>> +   struct acpi_device_id hid[2];
>> >>> +   struct x86_cpu_id cpu_ids[2];
>> >>
>> >> This really is x86-specific, so it should go into somewhere like
>> >> arch/x86/kernel/acpi/ or drivers/acpi/x86/ (not present yet).
>> >
>> > Ok, but then how do you want to hook this up, before you said
>> > that you wanted to deal with this in acpi_set_device_status(),
>> > which belongs in drivers/acpi/bus.c, do you want the x86
>> > code to provide something like a
>> >
>> > bool acpi_device_always_present(struct acpi_device *adev) {
>> > }
>> >
>> > Helper function and use that in the drivers/acpi/bus.c
>> > acpi_set_device_status() implementation ?
>>
>> Yes, something like that.
>>
>> In a header file you can make it depend on CONFIG_X86 and provide and
>> empty static inline stub for the "not defined" case.
>
> The PCI subsystem uses __weak stubs such as pcibios_add_bus() for arch-
> specific behaviour, or quirks which can be declared in arch/x86 to
> constrain them to this specific platform.
>
> Perhaps it makes sense to introduce ACPI quirks which can be declared
> the same way as PCI quirks to avoid cluttering the generic code with
> arch- or device-specific special cases.  So in this case we'd have
> something like:
>
> DECLARE_ACPI_FIXUP_STATUS(const char *hid, const char *uid, hook);
>
> And before calling _STA we'd check for presence of a fixup for the
> device in question.  Any additional stuff such as _HRV, CPU ID,
> DMI data could be checked in the fixup hook.  Thoughts?

Why don't we do that later if need be?

BTW, I'm not a big fan of __weak declarations as they result in dead
code being added to binaries.

> By the way:
>
>> >>> +void acpi_set_device_status(struct acpi_device *adev, u32 sta)
>> >>> +{
>> >>> +   u32 *status = (u32 *)&adev->status;
>> >>> +#ifdef CONFIG_X86
>> >>> +   u32 old_status = *status;
>> >>> +   int i;
>> >>> +
>> >>> +   /* acpi_match_device_ids checks status, so start with default */
>> >>> +   *status = ACPI_STA_DEFAULT;
>> >

[Intel-gfx] [PATCH v2] dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro

[Logan Gunthorpe]

Seeing the kunmap_atomic dma_buf_ops share the same name with a macro
in highmem.h, the former can be aliased if any dma-buf user includes
that header.

I'm personally trying to include highmem.h inside scatterlist.h and this
breaks the dma-buf code proper.

Christoph Hellwig suggested [1] renaming it and pushing this patch ASAP.

To maintain consistency I've renamed all four of kmap* and kunmap* to be
map* and unmap*. (Even though only kmap_atomic presently conflicts.)

[1] https://www.spinics.net/lists/target-devel/msg15070.html

Signed-off-by: Logan Gunthorpe 
Reviewed-by: Sinclair Yeh 
---

Changes since v1:

- Added the missing tegra driver (noticed by kbuild robot)
- Rebased off of drm-intel-next to get the i915 selftest that is new
- Fixed nits Sinclair pointed out.

 drivers/dma-buf/dma-buf.c  | 16 
 drivers/gpu/drm/armada/armada_gem.c|  8 
 drivers/gpu/drm/drm_prime.c|  8 
 drivers/gpu/drm/i915/i915_gem_dmabuf.c |  8 
 drivers/gpu/drm/i915/selftests/mock_dmabuf.c   |  8 
 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c  |  8 
 drivers/gpu/drm/tegra/gem.c|  8 
 drivers/gpu/drm/udl/udl_dmabuf.c   |  8 
 drivers/gpu/drm/vmwgfx/vmwgfx_prime.c  |  8 
 drivers/media/v4l2-core/videobuf2-dma-contig.c |  4 ++--
 drivers/media/v4l2-core/videobuf2-dma-sg.c |  4 ++--
 drivers/media/v4l2-core/videobuf2-vmalloc.c|  4 ++--
 drivers/staging/android/ion/ion.c  |  8 
 include/linux/dma-buf.h| 22 +++---
 14 files changed, 61 insertions(+), 61 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index f72aaac..512bdbc 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -405,8 +405,8 @@ struct dma_buf *dma_buf_export(const struct 
dma_buf_export_info *exp_info)
  || !exp_info->ops->map_dma_buf
  || !exp_info->ops->unmap_dma_buf
  || !exp_info->ops->release
- || !exp_info->ops->kmap_atomic
- || !exp_info->ops->kmap
+ || !exp_info->ops->map_atomic
+ || !exp_info->ops->map
  || !exp_info->ops->mmap)) {
return ERR_PTR(-EINVAL);
}
@@ -872,7 +872,7 @@ void *dma_buf_kmap_atomic(struct dma_buf *dmabuf, unsigned 
long page_num)
 {
WARN_ON(!dmabuf);

-   return dmabuf->ops->kmap_atomic(dmabuf, page_num);
+   return dmabuf->ops->map_atomic(dmabuf, page_num);
 }
 EXPORT_SYMBOL_GPL(dma_buf_kmap_atomic);

@@ -889,8 +889,8 @@ void dma_buf_kunmap_atomic(struct dma_buf *dmabuf, unsigned 
long page_num,
 {
WARN_ON(!dmabuf);

-   if (dmabuf->ops->kunmap_atomic)
-   dmabuf->ops->kunmap_atomic(dmabuf, page_num, vaddr);
+   if (dmabuf->ops->unmap_atomic)
+   dmabuf->ops->unmap_atomic(dmabuf, page_num, vaddr);
 }
 EXPORT_SYMBOL_GPL(dma_buf_kunmap_atomic);

@@ -907,7 +907,7 @@ void *dma_buf_kmap(struct dma_buf *dmabuf, unsigned long 
page_num)
 {
WARN_ON(!dmabuf);

-   return dmabuf->ops->kmap(dmabuf, page_num);
+   return dmabuf->ops->map(dmabuf, page_num);
 }
 EXPORT_SYMBOL_GPL(dma_buf_kmap);

@@ -924,8 +924,8 @@ void dma_buf_kunmap(struct dma_buf *dmabuf, unsigned long 
page_num,
 {
WARN_ON(!dmabuf);

-   if (dmabuf->ops->kunmap)
-   dmabuf->ops->kunmap(dmabuf, page_num, vaddr);
+   if (dmabuf->ops->unmap)
+   dmabuf->ops->unmap(dmabuf, page_num, vaddr);
 }
 EXPORT_SYMBOL_GPL(dma_buf_kunmap);

diff --git a/drivers/gpu/drm/armada/armada_gem.c 
b/drivers/gpu/drm/armada/armada_gem.c
index 1597458..d6c2a5d 100644
--- a/drivers/gpu/drm/armada/armada_gem.c
+++ b/drivers/gpu/drm/armada/armada_gem.c
@@ -529,10 +529,10 @@ static const struct dma_buf_ops 
armada_gem_prime_dmabuf_ops = {
.map_dma_buf= armada_gem_prime_map_dma_buf,
.unmap_dma_buf  = armada_gem_prime_unmap_dma_buf,
.release= drm_gem_dmabuf_release,
-   .kmap_atomic= armada_gem_dmabuf_no_kmap,
-   .kunmap_atomic  = armada_gem_dmabuf_no_kunmap,
-   .kmap   = armada_gem_dmabuf_no_kmap,
-   .kunmap = armada_gem_dmabuf_no_kunmap,
+   .map_atomic = armada_gem_dmabuf_no_kmap,
+   .unmap_atomic   = armada_gem_dmabuf_no_kunmap,
+   .map= armada_gem_dmabuf_no_kmap,
+   .unmap  = armada_gem_dmabuf_no_kunmap,
.mmap   = armada_gem_dmabuf_mmap,
 };

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 9fb65b7..954eb84 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -403,10 +403,10 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops 
=  {
.map_dma_buf = drm_gem_map_dma_buf,
.unmap_dma_

[Intel-gfx] [PATCH v6 13/20] drm/i915/guc: Provide register list to be saved/restored during engine reset

[Michel Thierry]

From: Arun Siluvery 

GuC expects a list of registers from the driver which are saved/restored
during engine reset. The type of value to be saved is controlled by
flags. We provide a minimal set of registers that we want GuC to save and
restore. This is not an issue in case of engine reset as driver initializes
most of them following an engine reset, but in case of media reset (aka
watchdog reset) which is completely internal to GuC (including resubmission
of hung workload), it is necessary to provide this list, otherwise GuC won't
be able to schedule further workloads after a reset. This is the minimal
set of registers identified for things to work as expected but if we see
any new issues, this register list can be expanded.

In order to not loose any existing workarounds, we have to let GuC know
the registers and its values. These will be reapplied after the reset.
Note that we can't just read the current value because most of these
registers are masked (so we have a workaround for a workaround for a
workaround).

v2: REGSET_MASKED is too difficult for GuC, use REGSET_SAVE_DEFAULT_VALUE
and current value from RING_MODE reg instead; no need to preserve
head/tail either, be extra paranoid and save whitelisted registers (Daniele).

v3: Workarounds added only once during _init_workarounds also have to
been restored, or we risk loosing them after internal GuC reset
(Daniele).

Cc: Daniele Ceraolo Spurio 
Signed-off-by: Arun Siluvery 
Signed-off-by: Jeff McGee 
Signed-off-by: Michel Thierry 
---
 drivers/gpu/drm/i915/i915_drv.h|  3 ++
 drivers/gpu/drm/i915/i915_guc_submission.c | 68 +-
 drivers/gpu/drm/i915/intel_engine_cs.c | 65 +++-
 3 files changed, 114 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index fa3988c5033b..1ba1ac016973 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1913,7 +1913,10 @@ struct i915_wa_reg {
 
 struct i915_workarounds {
struct i915_wa_reg reg[I915_MAX_WA_REGS];
+   /* list of registers (and their values) that GuC will have to restore */
+   struct i915_wa_reg guc_reg[GUC_REGSET_MAX_REGISTERS];
u32 count;
+   u32 guc_count;
u32 hw_whitelist_count[I915_NUM_ENGINES];
 };
 
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 1ea36a88d2fb..f4081da88df2 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -1003,6 +1003,24 @@ static void guc_policies_init(struct guc_policies 
*policies)
policies->is_valid = 1;
 }
 
+/*
+ * In this macro it is highly unlikely to exceed max value but even if we did
+ * it is not an error so just throw a warning and continue. Only side effect
+ * in continuing further means some registers won't be added to save/restore
+ * list.
+ */
+#define GUC_ADD_MMIO_REG_ADS(node, reg_addr, _flags, defvalue) \
+   do {\
+   u32 __count = node->number_of_registers;\
+   if (WARN_ON(__count >= GUC_REGSET_MAX_REGISTERS))   \
+   continue;   \
+   node->registers[__count].offset = reg_addr.reg; \
+   node->registers[__count].flags = (_flags);  \
+   if (defvalue)   \
+   node->registers[__count].value = (defvalue);\
+   node->number_of_registers++;\
+   } while (0)
+
 static int guc_ads_create(struct intel_guc *guc)
 {
struct drm_i915_private *dev_priv = guc_to_i915(guc);
@@ -1016,6 +1034,7 @@ static int guc_ads_create(struct intel_guc *guc)
u8 reg_state_buffer[GUC_S3_SAVE_SPACE_PAGES * PAGE_SIZE];
} __packed *blob;
struct intel_engine_cs *engine;
+   struct i915_workarounds *workarounds = &dev_priv->workarounds;
enum intel_engine_id id;
u32 base;
 
@@ -1035,6 +1054,47 @@ static int guc_ads_create(struct intel_guc *guc)
 
/* MMIO reg state */
for_each_engine(engine, dev_priv, id) {
+   u32 i;
+   struct guc_mmio_regset *eng_reg =
+   &blob->reg_state.engine_reg[engine->guc_id];
+
+   /*
+* Provide a list of registers to be saved/restored during gpu
+* reset. This is mainly required for Media reset (aka watchdog
+* timeout) which is completely under the control of GuC
+* (resubmission of hung workload is handled inside GuC).
+*/
+   GUC_ADD_MMIO_REG_ADS(eng_reg, RING_HWS_PGA(engine->mmio_base),
+GUC_REGSET_ENGINERESET |
+GUC_REGSET_SA

Re: [Intel-gfx] [PATCH 02/27] drm/i915: Mark CPU cache as dirty on every transition for CPU writes

[Chris Wilson]

On Wed, Apr 19, 2017 at 11:13:17AM -0700, Dongwon Kim wrote:
> Chris,
> 
> Just to make sure, you want to just remove write_domain check from 
> if statement before clflush in execbuffer_move_to_gpu. Am I right?
> I will try both (cache_dirty only vs cache_dirty & !cache_coherent)
> and get back to you shortly. 

Yes, I just don't have a single bit for cache_coherent yet, so you
might as well let that call i915_gem_object_clflush().
-Chris

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

Re: [Intel-gfx] [PATCH 02/27] drm/i915: Mark CPU cache as dirty on every transition for CPU writes

[Dongwon Kim]

Chris,

Just to make sure, you want to just remove write_domain check from 
if statement before clflush in execbuffer_move_to_gpu. Am I right?
I will try both (cache_dirty only vs cache_dirty & !cache_coherent)
and get back to you shortly. 

On Wed, Apr 19, 2017 at 07:08:33PM +0100, Chris Wilson wrote:
> On Wed, Apr 19, 2017 at 09:52:28AM -0700, Dongwon Kim wrote:
> > I tried your patch but it didn't fix the original 
> > problem. I think it is somehow related to the flushing condition
> > here:
> > 
> > @@ -1129,10 +1129,8 @@ i915_gem_execbuffer_move_to_gpu(struct 
> > drm_i915_gem_request *req,
> > if (vma->exec_entry->flags & EXEC_OBJECT_ASYNC)
> > continue;
> > 
> > if (obj->base.write_domain & I915_GEM_DOMAIN_CPU) {
> > +   if (obj->base.write_domain & obj->cache_dirty)
> > i915_gem_clflush_object(obj, 0);
> > -   obj->base.write_domain = 0;
> > -   }
> > 
> > here, we do clflush only if write_domain is not 0 even if cache_dirty
> > flag is set after your patch is applied.
> 
> This can be just reduced to if (obj->cache_dirty) clflush().
> 
> We're slightly better in that we don't set obj->cache_dirty so often for
> normal gpu rendering (just on transitions away from the gpu now), but it
> still means we will be redundantly checking for clflushes prior to
> rendering.
> 
> Can you double check that this patch + if (obj->cache_dirty) works for you?
> 
> What I guess I really want here is
>   if (obj->cache_dirty & !obj->cache_coherent)
> essentially inlining the check from clflush.
> -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 v6 16/20] drm/i915: Watchdog timeout: IRQ handler for gen8+

[Michel Thierry]

On 19/04/17 10:51, Chris Wilson wrote:

On Wed, Apr 19, 2017 at 10:11:37AM -0700, Michel Thierry wrote:



On 19/04/17 03:20, Chris Wilson wrote:

On Tue, Apr 18, 2017 at 01:23:31PM -0700, Michel Thierry wrote:

*** General ***

Watchdog timeout (or "media engine reset") is a feature that allows
userland applications to enable hang detection on individual batch buffers.
The detection mechanism itself is mostly bound to the hardware and the only
thing that the driver needs to do to support this form of hang detection
is to implement the interrupt handling support as well as watchdog command
emission before and after the emitted batch buffer start instruction in the
ring buffer.

The principle of the hang detection mechanism is as follows:

1. Once the decision has been made to enable watchdog timeout for a
particular batch buffer and the driver is in the process of emitting the
batch buffer start instruction into the ring buffer it also emits a
watchdog timer start instruction before and a watchdog timer cancellation
instruction after the batch buffer start instruction in the ring buffer.

2. Once the GPU execution reaches the watchdog timer start instruction
the hardware watchdog counter is started by the hardware. The counter
keeps counting until either reaching a previously configured threshold
value or the timer cancellation instruction is executed.

2a. If the counter reaches the threshold value the hardware fires a
watchdog interrupt that is picked up by the watchdog interrupt handler.
This means that a hang has been detected and the driver needs to deal with
it the same way it would deal with a engine hang detected by the periodic
hang checker. The only difference between the two is that we already blamed
the active request (to ensure an engine reset).

2b. If the batch buffer completes and the execution reaches the watchdog
cancellation instruction before the watchdog counter reaches its
threshold value the watchdog is cancelled and nothing more comes of it.
No hang is detected.

Note about future interaction with preemption: Preemption could happen
in a command sequence prior to watchdog counter getting disabled,
resulting in watchdog being triggered following preemption. The driver will
need to explicitly disable the watchdog counter as part of the
preemption sequence.


Does MI_ARB_ON_OFF do the trick? Shouldn't we basically be only turning
preemption on for the user buffers as it just causes hassle if we allow
preemption in our preamble + breadcrumb. (And there's little point in
preempting in the flushes.)



Mid-batch?
The watchdog counter is not aware of MI_ARB_ON_OFF (or any other
cmd) and would keep running / expire. We could call
emit_stop_watchdog unconditionally to prevent this.


No, I was thinking of the opposite where we had preemption after the
batch. Completely missed the point of the watchdog being abled for the
low priority batch then being inherited by the high priority batch - and
vice versa that the watchdog counter would not be restored on the
context switch back. Does suggest that the watchdog should really be
part of the context image...


RING_CNTR (0x2178) & RING_THRESH (0x217c) are part of the context image, 
but there's still the issue of the ctx restore being slower (or maybe 
it's a lite-restore).


And the 'counter' isn't part of the image; when the pre-empted batch 
resumes, the counter will re-start from 0.

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

Re: [Intel-gfx] [PATCH 02/27] drm/i915: Mark CPU cache as dirty on every transition for CPU writes

[Chris Wilson]

On Wed, Apr 19, 2017 at 09:52:28AM -0700, Dongwon Kim wrote:
> I tried your patch but it didn't fix the original 
> problem. I think it is somehow related to the flushing condition
> here:
> 
> @@ -1129,10 +1129,8 @@ i915_gem_execbuffer_move_to_gpu(struct 
> drm_i915_gem_request *req,
>   if (vma->exec_entry->flags & EXEC_OBJECT_ASYNC)
>   continue;
> 
>   if (obj->base.write_domain & I915_GEM_DOMAIN_CPU) {
> + if (obj->base.write_domain & obj->cache_dirty)
>   i915_gem_clflush_object(obj, 0);
> - obj->base.write_domain = 0;
> - }
> 
> here, we do clflush only if write_domain is not 0 even if cache_dirty
> flag is set after your patch is applied.

This can be just reduced to if (obj->cache_dirty) clflush().

We're slightly better in that we don't set obj->cache_dirty so often for
normal gpu rendering (just on transitions away from the gpu now), but it
still means we will be redundantly checking for clflushes prior to
rendering.

Can you double check that this patch + if (obj->cache_dirty) works for you?

What I guess I really want here is
if (obj->cache_dirty & !obj->cache_coherent)
essentially inlining the check from clflush.
-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 v6 16/20] drm/i915: Watchdog timeout: IRQ handler for gen8+

[Chris Wilson]

On Wed, Apr 19, 2017 at 10:11:37AM -0700, Michel Thierry wrote:
> 
> 
> On 19/04/17 03:20, Chris Wilson wrote:
> >On Tue, Apr 18, 2017 at 01:23:31PM -0700, Michel Thierry wrote:
> >>*** General ***
> >>
> >>Watchdog timeout (or "media engine reset") is a feature that allows
> >>userland applications to enable hang detection on individual batch buffers.
> >>The detection mechanism itself is mostly bound to the hardware and the only
> >>thing that the driver needs to do to support this form of hang detection
> >>is to implement the interrupt handling support as well as watchdog command
> >>emission before and after the emitted batch buffer start instruction in the
> >>ring buffer.
> >>
> >>The principle of the hang detection mechanism is as follows:
> >>
> >>1. Once the decision has been made to enable watchdog timeout for a
> >>particular batch buffer and the driver is in the process of emitting the
> >>batch buffer start instruction into the ring buffer it also emits a
> >>watchdog timer start instruction before and a watchdog timer cancellation
> >>instruction after the batch buffer start instruction in the ring buffer.
> >>
> >>2. Once the GPU execution reaches the watchdog timer start instruction
> >>the hardware watchdog counter is started by the hardware. The counter
> >>keeps counting until either reaching a previously configured threshold
> >>value or the timer cancellation instruction is executed.
> >>
> >>2a. If the counter reaches the threshold value the hardware fires a
> >>watchdog interrupt that is picked up by the watchdog interrupt handler.
> >>This means that a hang has been detected and the driver needs to deal with
> >>it the same way it would deal with a engine hang detected by the periodic
> >>hang checker. The only difference between the two is that we already blamed
> >>the active request (to ensure an engine reset).
> >>
> >>2b. If the batch buffer completes and the execution reaches the watchdog
> >>cancellation instruction before the watchdog counter reaches its
> >>threshold value the watchdog is cancelled and nothing more comes of it.
> >>No hang is detected.
> >>
> >>Note about future interaction with preemption: Preemption could happen
> >>in a command sequence prior to watchdog counter getting disabled,
> >>resulting in watchdog being triggered following preemption. The driver will
> >>need to explicitly disable the watchdog counter as part of the
> >>preemption sequence.
> >
> >Does MI_ARB_ON_OFF do the trick? Shouldn't we basically be only turning
> >preemption on for the user buffers as it just causes hassle if we allow
> >preemption in our preamble + breadcrumb. (And there's little point in
> >preempting in the flushes.)
> >
> 
> Mid-batch?
> The watchdog counter is not aware of MI_ARB_ON_OFF (or any other
> cmd) and would keep running / expire. We could call
> emit_stop_watchdog unconditionally to prevent this.

No, I was thinking of the opposite where we had preemption after the
batch. Completely missed the point of the watchdog being abled for the
low priority batch then being inherited by the high priority batch - and
vice versa that the watchdog counter would not be restored on the
context switch back. Does suggest that the watchdog should really be
part of the context image...
-Chris

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

Re: [Intel-gfx] [PATCH 02/27] drm/i915: Mark CPU cache as dirty on every transition for CPU writes

[Chris Wilson]

On Wed, Apr 19, 2017 at 09:52:28AM -0700, Dongwon Kim wrote:
> I tried your patch but it didn't fix the original 
> problem. I think it is somehow related to the flushing condition
> here:

I don't think I actually checked what GPU you observed it on - I was
assuming llc, since that was the last bug we had.
-Chris

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

Re: [Intel-gfx] [PATCH 02/27] drm/i915: Mark CPU cache as dirty on every transition for CPU writes

[Chris Wilson]

On Wed, Apr 19, 2017 at 09:52:28AM -0700, Dongwon Kim wrote:
> I tried your patch but it didn't fix the original 
> problem. I think it is somehow related to the flushing condition
> here:
> 
> @@ -1129,10 +1129,8 @@ i915_gem_execbuffer_move_to_gpu(struct 
> drm_i915_gem_request *req,
>   if (vma->exec_entry->flags & EXEC_OBJECT_ASYNC)
>   continue;
> 
>   if (obj->base.write_domain & I915_GEM_DOMAIN_CPU) {
> + if (obj->base.write_domain & obj->cache_dirty)
>   i915_gem_clflush_object(obj, 0);
> - obj->base.write_domain = 0;
> - }
> 
> here, we do clflush only if write_domain is not 0 even if cache_dirty
> flag is set after your patch is applied.
> 
> And now please look at this:
> 
> @@ -753,6 +766,11 @@ flush_write_domain(struct drm_i915_gem_object *obj, 
> unsigned int flush_domains)
> case I915_GEM_DOMAIN_CPU:
> i915_gem_clflush_object(obj, I915_CLFLUSH_SYNC);
> break;
> +
> +   case I915_GEM_DOMAIN_RENDER:
> +   if (gpu_write_needs_clflush(obj))
> +   obj->cache_dirty = true;
> +   break;
> }
> 
> obj->base.write_domain=0;
> 
> So here, if the write_domain is I915_GEM_DOMAIN_RENDER, we set cache_dirty to 
> true
> then reset write_domain.
> 
> So right after this flush_write_domain call, write_domain will be 0 but cache 
> is
> still dirty. I am wondering if this is where that condition (write_domain==0 
> and 
> cache_dirty==1) originally came from.

And we definitely do not want to be flushing the cache for the GPU after
a GPU write. We only want for that cache to be flushed after the GPU if
it is moved to a non-coherent domain. That's the challenge.

I was also expecting that (incoherent) reads from the GPU would go through
the cache - we make the same assumption for CPU reads.

Thanks for testing, definitely back to the drawing board. Hmm, might be
worth taking the alternative approach and to always schedule an async
clflush in set-cache-domain. Just have to check that we have appropriate
waits and don't have any inappropriate ones.
-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 v6 16/20] drm/i915: Watchdog timeout: IRQ handler for gen8+

[Michel Thierry]

On 19/04/17 03:20, Chris Wilson wrote:

On Tue, Apr 18, 2017 at 01:23:31PM -0700, Michel Thierry wrote:

*** General ***

Watchdog timeout (or "media engine reset") is a feature that allows
userland applications to enable hang detection on individual batch buffers.
The detection mechanism itself is mostly bound to the hardware and the only
thing that the driver needs to do to support this form of hang detection
is to implement the interrupt handling support as well as watchdog command
emission before and after the emitted batch buffer start instruction in the
ring buffer.

The principle of the hang detection mechanism is as follows:

1. Once the decision has been made to enable watchdog timeout for a
particular batch buffer and the driver is in the process of emitting the
batch buffer start instruction into the ring buffer it also emits a
watchdog timer start instruction before and a watchdog timer cancellation
instruction after the batch buffer start instruction in the ring buffer.

2. Once the GPU execution reaches the watchdog timer start instruction
the hardware watchdog counter is started by the hardware. The counter
keeps counting until either reaching a previously configured threshold
value or the timer cancellation instruction is executed.

2a. If the counter reaches the threshold value the hardware fires a
watchdog interrupt that is picked up by the watchdog interrupt handler.
This means that a hang has been detected and the driver needs to deal with
it the same way it would deal with a engine hang detected by the periodic
hang checker. The only difference between the two is that we already blamed
the active request (to ensure an engine reset).

2b. If the batch buffer completes and the execution reaches the watchdog
cancellation instruction before the watchdog counter reaches its
threshold value the watchdog is cancelled and nothing more comes of it.
No hang is detected.

Note about future interaction with preemption: Preemption could happen
in a command sequence prior to watchdog counter getting disabled,
resulting in watchdog being triggered following preemption. The driver will
need to explicitly disable the watchdog counter as part of the
preemption sequence.


Does MI_ARB_ON_OFF do the trick? Shouldn't we basically be only turning
preemption on for the user buffers as it just causes hassle if we allow
preemption in our preamble + breadcrumb. (And there's little point in
preempting in the flushes.)



Mid-batch?
The watchdog counter is not aware of MI_ARB_ON_OFF (or any other cmd) 
and would keep running / expire. We could call emit_stop_watchdog 
unconditionally to prevent this.



*** This patch introduces: ***

1. IRQ handler code for watchdog timeout allowing direct hang recovery
based on hardware-driven hang detection, which then integrates directly
with the hang recovery path. This is independent of having per-engine reset
or just full gpu reset.

2. Watchdog specific register information.

Currently the render engine and all available media engines support
watchdog timeout (VECS is only supported in GEN9). The specifications elude
to the BCS engine being supported but that is currently not supported by
this commit.

Note that the value to stop the counter is different between render and
non-render engines in GEN8; GEN9 onwards it's the same.


Should mention the choice to piggyback the current hangcheck + capture
scheme.


+   if (iir & (GT_GEN8_WATCHDOG_INTERRUPT << test_shift)) {
+   tasklet_schedule(&engine->watchdog_tasklet);
+   }


Kill unwanted braces.


+#define GEN8_WATCHDOG_1000US 0x2ee0 //XXX: Temp, replace with helper function
+static void gen8_watchdog_irq_handler(unsigned long data)
+{
+   struct intel_engine_cs *engine = (struct intel_engine_cs *)data;
+   struct drm_i915_private *dev_priv = engine->i915;
+   u32 current_seqno;
+
+   intel_uncore_forcewake_get(dev_priv, engine->fw_domains);
+
+   /* Stop the counter to prevent further timeout interrupts */
+   I915_WRITE_FW(RING_CNTR(engine->mmio_base), 
get_watchdog_disable(engine));
+
+   current_seqno = intel_engine_get_seqno(engine);
+
+   /* did the request complete after the timer expired? */
+   if (intel_engine_last_submit(engine) == current_seqno)
+   goto fw_put;
+
+   if (engine->hangcheck.watchdog == current_seqno) {
+   /* Make sure the active request will be marked as guilty */
+   engine->hangcheck.stalled = true;
+   engine->hangcheck.seqno = intel_engine_get_seqno(engine);


Use current_seqno again. intel_engine_get_seqno() may have just changed.
-Chris


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

Re: [Intel-gfx] [PATCH] dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro

[Sinclair Yeh]

Minor nits, otherwise the vmwgfx part,
  Reviewed-by: Sinclair Yeh 

On Tue, Apr 18, 2017 at 06:17:00PM -0600, Logan Gunthorpe wrote:
> Seeing the kunmap_atomic dma_buf_op shares the same name with a macro
s^

> in higmem.h, the former can be aliased if any dma-buf user includes
   h^
> that header.
> 
> I'm personally trying to include highmem.h inside scatterlist.h and this
> breaks the dma-buf code proper.
> 
> Christoph Hellwig suggested [1] renaming it and pushing this patch ASAP.
> 
> To maintain consistency I've renamed all four of kmap* and kunmap* to be
> map* and unmap*. (Even though only kmap_atomic presently conflicts.)
> 
> [1] 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.spinics.net_lists_target-2Ddevel_msg15070.html&d=DwIBAg&c=uilaK90D4TOVoH58JNXRgQ&r=HaJ2a6NYExoV0cntAYcoqA&m=QP_jolGTC4ofBnHRnAs0tFIXHnVWaTT0AdMyCL9SM64&s=un2hxBL1283iOTtJeJnvyyvtAu1d5Imyh5Q7AzljrfQ&e=
>  
> 
> Signed-off-by: Logan Gunthorpe 
> ---
>  drivers/dma-buf/dma-buf.c  | 16 
>  drivers/gpu/drm/armada/armada_gem.c|  8 
>  drivers/gpu/drm/drm_prime.c|  8 
>  drivers/gpu/drm/i915/i915_gem_dmabuf.c |  8 
>  drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c  |  8 
>  drivers/gpu/drm/tegra/gem.c|  4 ++--
>  drivers/gpu/drm/udl/udl_dmabuf.c   |  8 
>  drivers/gpu/drm/vmwgfx/vmwgfx_prime.c  |  8 
>  drivers/media/v4l2-core/videobuf2-dma-contig.c |  4 ++--
>  drivers/media/v4l2-core/videobuf2-dma-sg.c |  4 ++--
>  drivers/media/v4l2-core/videobuf2-vmalloc.c|  4 ++--
>  drivers/staging/android/ion/ion.c  |  8 
>  include/linux/dma-buf.h| 22 +++---
>  13 files changed, 55 insertions(+), 55 deletions(-)
> 
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 0007b79..7cc2bfe 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -405,8 +405,8 @@ struct dma_buf *dma_buf_export(const struct 
> dma_buf_export_info *exp_info)
> || !exp_info->ops->map_dma_buf
> || !exp_info->ops->unmap_dma_buf
> || !exp_info->ops->release
> -   || !exp_info->ops->kmap_atomic
> -   || !exp_info->ops->kmap
> +   || !exp_info->ops->map_atomic
> +   || !exp_info->ops->map
> || !exp_info->ops->mmap)) {
>   return ERR_PTR(-EINVAL);
>   }
> @@ -872,7 +872,7 @@ void *dma_buf_kmap_atomic(struct dma_buf *dmabuf, 
> unsigned long page_num)
>  {
>   WARN_ON(!dmabuf);
>  
> - return dmabuf->ops->kmap_atomic(dmabuf, page_num);
> + return dmabuf->ops->map_atomic(dmabuf, page_num);
>  }
>  EXPORT_SYMBOL_GPL(dma_buf_kmap_atomic);
>  
> @@ -889,8 +889,8 @@ void dma_buf_kunmap_atomic(struct dma_buf *dmabuf, 
> unsigned long page_num,
>  {
>   WARN_ON(!dmabuf);
>  
> - if (dmabuf->ops->kunmap_atomic)
> - dmabuf->ops->kunmap_atomic(dmabuf, page_num, vaddr);
> + if (dmabuf->ops->unmap_atomic)
> + dmabuf->ops->unmap_atomic(dmabuf, page_num, vaddr);
>  }
>  EXPORT_SYMBOL_GPL(dma_buf_kunmap_atomic);
>  
> @@ -907,7 +907,7 @@ void *dma_buf_kmap(struct dma_buf *dmabuf, unsigned long 
> page_num)
>  {
>   WARN_ON(!dmabuf);
>  
> - return dmabuf->ops->kmap(dmabuf, page_num);
> + return dmabuf->ops->map(dmabuf, page_num);
>  }
>  EXPORT_SYMBOL_GPL(dma_buf_kmap);
>  
> @@ -924,8 +924,8 @@ void dma_buf_kunmap(struct dma_buf *dmabuf, unsigned long 
> page_num,
>  {
>   WARN_ON(!dmabuf);
>  
> - if (dmabuf->ops->kunmap)
> - dmabuf->ops->kunmap(dmabuf, page_num, vaddr);
> + if (dmabuf->ops->unmap)
> + dmabuf->ops->unmap(dmabuf, page_num, vaddr);
>  }
>  EXPORT_SYMBOL_GPL(dma_buf_kunmap);
>  
> diff --git a/drivers/gpu/drm/armada/armada_gem.c 
> b/drivers/gpu/drm/armada/armada_gem.c
> index 1597458..d6c2a5d 100644
> --- a/drivers/gpu/drm/armada/armada_gem.c
> +++ b/drivers/gpu/drm/armada/armada_gem.c
> @@ -529,10 +529,10 @@ static const struct dma_buf_ops 
> armada_gem_prime_dmabuf_ops = {
>   .map_dma_buf= armada_gem_prime_map_dma_buf,
>   .unmap_dma_buf  = armada_gem_prime_unmap_dma_buf,
>   .release= drm_gem_dmabuf_release,
> - .kmap_atomic= armada_gem_dmabuf_no_kmap,
> - .kunmap_atomic  = armada_gem_dmabuf_no_kunmap,
> - .kmap   = armada_gem_dmabuf_no_kmap,
> - .kunmap = armada_gem_dmabuf_no_kunmap,
> + .map_atomic = armada_gem_dmabuf_no_kmap,
> + .unmap_atomic   = armada_gem_dmabuf_no_kunmap,
> + .map= armada_gem_dmabuf_no_kmap,
> + .unmap  = armada_gem_dmabuf_no_kunmap,
>   .mmap   = armada_gem_dmabuf_mmap,
>  };
>  
> diff --git a/drivers/gpu/drm/drm_prime.c b/d

Re: [Intel-gfx] [PATCH v6 18/20] drm/i915: Watchdog timeout: DRM kernel interface to set the timeout

[Daniele Ceraolo Spurio]

On 18/04/17 13:23, Michel Thierry wrote:

Final enablement patch for GPU hang detection using watchdog timeout.
Using the gem_context_setparam ioctl, users can specify the desired
timeout value in microseconds, and the driver will do the conversion to
'timestamps'.

The recommended default watchdog threshold for video engines is 6 us,
since this has been _empirically determined_ to be a good compromise for
low-latency requirements and low rate of false positives. The default
register value is ~106000us and the theoretical max value (all 1s) is
353 seconds.

Note, UABI engine ids and i915 engine ids are different, and this patch
uses the i915 ones. Some kind of mapping table [1] is required if we
decide to use the UABI engine ids.

[1] 
http://patchwork.freedesktop.org/patch/msgid/20170329135831.30254-2-ch...@chris-wilson.co.uk


Now that we have class and instance definitions, could it be worth to 
use those instead to index the engines? If we pair it with the engine 
discovery ioctl that Tvrtko proposed we could have something that is 
reasonably future-proof.


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

Re: [Intel-gfx] [PATCH i-g-t 08/13] benchmarks/Android.mk: Add gem_latency to skip list

[Chris Wilson]

On Wed, Apr 19, 2017 at 01:01:50PM +0200, Arkadiusz Hiler wrote:
> AOSP, as of this commit, does not include libdrm with fence defines.

Pushed local defines that should keep the benchmark happy.

Please do reset the configure libdrm requirements to what is available
on min(Android, debian stable). They should be our compile targets.
-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 v6 18/20] drm/i915: Watchdog timeout: DRM kernel interface to set the timeout

[Jeff McGee]

On Tue, Apr 18, 2017 at 01:23:33PM -0700, Michel Thierry wrote:
> Final enablement patch for GPU hang detection using watchdog timeout.
> Using the gem_context_setparam ioctl, users can specify the desired
> timeout value in microseconds, and the driver will do the conversion to
> 'timestamps'.
> 
> The recommended default watchdog threshold for video engines is 6 us,
> since this has been _empirically determined_ to be a good compromise for
> low-latency requirements and low rate of false positives. The default
> register value is ~106000us and the theoretical max value (all 1s) is
> 353 seconds.
> 
> Note, UABI engine ids and i915 engine ids are different, and this patch
> uses the i915 ones. Some kind of mapping table [1] is required if we
> decide to use the UABI engine ids.
> 
> [1] 
> http://patchwork.freedesktop.org/patch/msgid/20170329135831.30254-2-ch...@chris-wilson.co.uk
> 
> v2: Fixed get api to return values in microseconds. Threshold updated to
> be per context engine. Check for u32 overflow. Capture ctx threshold
> value in error state.
> 
> v3: Add a way to get array size, short-cut to disable all thresholds,
> return EFAULT / EINVAL as needed. Move the capture of the threshold
> value in the error state into a new patch. BXT has a different
> timestamp base (because why not?).
> 
> Signed-off-by: Tomas Elf 
> Signed-off-by: Arun Siluvery 
> Signed-off-by: Michel Thierry 
> ---
>  drivers/gpu/drm/i915/i915_drv.h |  29 +
>  drivers/gpu/drm/i915/i915_gem_context.c | 102 
> 
>  drivers/gpu/drm/i915/intel_lrc.c|   5 +-
>  include/uapi/drm/i915_drm.h |   1 +
>  4 files changed, 135 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 203f2112dd18..f65a236fddef 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3574,6 +3574,35 @@ i915_gem_context_lookup_timeline(struct 
> i915_gem_context *ctx,
>   return &vm->timeline.engine[engine->id];
>  }
>  
> +/*
> + * BDW & SKL+ Timestamp timer resolution = 0.080 uSec,
> + * or 1250 counts per second, or ~12 counts per microsecond.
> + *
> + * But Broxton Timestamp timer resolution is different, 0.052 uSec,
> + * or 1920 counts per second, or ~19 counts per microsecond.
> + */
> +#define SKL_TIMESTAMP_CNTS_PER_USEC 12
> +#define BXT_TIMESTAMP_CNTS_PER_USEC 19
> +#define TIMESTAMP_CNTS_PER_USEC(dev_priv) (IS_BROXTON(dev_priv) ? \
> +BXT_TIMESTAMP_CNTS_PER_USEC : \
> +SKL_TIMESTAMP_CNTS_PER_USEC)
> +static inline u32
> +watchdog_to_us(struct drm_i915_private *dev_priv, u32 value_in_clock_counts)
> +{
> + return value_in_clock_counts / TIMESTAMP_CNTS_PER_USEC(dev_priv);
> +}
> +
> +static inline u32
> +watchdog_to_clock_counts(struct drm_i915_private *dev_priv, u64 value_in_us)
> +{
> + u64 threshold = value_in_us * TIMESTAMP_CNTS_PER_USEC(dev_priv);
> +
> + if (overflows_type(threshold, u32))
> + return -EINVAL;
> +
> + return threshold;
> +}
> +
>  int i915_perf_open_ioctl(struct drm_device *dev, void *data,
>struct drm_file *file);
>  
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
> b/drivers/gpu/drm/i915/i915_gem_context.c
> index edbed85a1c88..85a6467a25a6 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> @@ -422,6 +422,102 @@ i915_gem_context_create_gvt(struct drm_device *dev)
>   return ctx;
>  }
>  
> +/* Return the timer count threshold in microseconds. */
> +int i915_gem_context_get_watchdog(struct i915_gem_context *ctx,
> +   struct drm_i915_gem_context_param *args)
> +{
> + struct drm_i915_private *dev_priv = ctx->i915;
> + struct intel_engine_cs *engine;
> + enum intel_engine_id id;
> + u32 threshold_in_us[I915_NUM_ENGINES];
> +
> + if (args->size == 0)
> + goto out;
> +
> + if (args->size < sizeof(threshold_in_us))
> + return -EFAULT;
> +
> + if (!dev_priv->engine[VCS]->emit_start_watchdog)
> + return -ENODEV;
> +
> + for_each_engine(engine, dev_priv, id) {
> + struct intel_context *ce = &ctx->engine[id];
> +
> + threshold_in_us[id] = watchdog_to_us(dev_priv,
> +  ce->watchdog_threshold);
> + }
> +
> + mutex_unlock(&dev_priv->drm.struct_mutex);
> + if (__copy_to_user(u64_to_user_ptr(args->value),
> +&threshold_in_us,
> +sizeof(threshold_in_us))) {
> + mutex_lock(&dev_priv->drm.struct_mutex);
> + return -EFAULT;
> + }
> + mutex_lock(&dev_priv->drm.struct_mutex);
> +
> +out:
> + args->size = sizeof(threshold_in_us);
> +
> + return 0;
> +}
> +
> +/*
> + * Based on time out value in microseconds (

Re: [Intel-gfx] [PATCH 02/27] drm/i915: Mark CPU cache as dirty on every transition for CPU writes

[Dongwon Kim]

I tried your patch but it didn't fix the original 
problem. I think it is somehow related to the flushing condition
here:

@@ -1129,10 +1129,8 @@ i915_gem_execbuffer_move_to_gpu(struct 
drm_i915_gem_request *req,
if (vma->exec_entry->flags & EXEC_OBJECT_ASYNC)
continue;

if (obj->base.write_domain & I915_GEM_DOMAIN_CPU) {
+   if (obj->base.write_domain & obj->cache_dirty)
i915_gem_clflush_object(obj, 0);
-   obj->base.write_domain = 0;
-   }

here, we do clflush only if write_domain is not 0 even if cache_dirty
flag is set after your patch is applied.

And now please look at this:

@@ -753,6 +766,11 @@ flush_write_domain(struct drm_i915_gem_object *obj, 
unsigned int flush_domains)
case I915_GEM_DOMAIN_CPU:
i915_gem_clflush_object(obj, I915_CLFLUSH_SYNC);
break;
+
+   case I915_GEM_DOMAIN_RENDER:
+   if (gpu_write_needs_clflush(obj))
+   obj->cache_dirty = true;
+   break;
}

obj->base.write_domain=0;

So here, if the write_domain is I915_GEM_DOMAIN_RENDER, we set cache_dirty to 
true
then reset write_domain.

So right after this flush_write_domain call, write_domain will be 0 but cache is
still dirty. I am wondering if this is where that condition (write_domain==0 
and 
cache_dirty==1) originally came from.

On Wed, Apr 19, 2017 at 10:41:18AM +0100, Chris Wilson wrote:
> Currently, we only mark the CPU cache as dirty if we skip a clflush.
> This leads to some confusion where we have to ask if the object is in
> the write domain or missed a clflush. If we always mark the cache as
> dirty, this becomes a much simply question to answer.
> 
> The goal remains to do as few clflushes as required and to do them as
> late as possible, in the hope of deferring the work to a kthread and not
> block the caller (e.g. execbuf, flips).
> 
> Reported-by: Dongwon Kim 
> Fixes: a6a7cc4b7db6 ("drm/i915: Always flush the dirty CPU cache when pinning 
> the scanout")
> Signed-off-by: Chris Wilson 
> Cc: Dongwon Kim 
> Cc: Matt Roper 
> ---
>  drivers/gpu/drm/i915/i915_gem.c  | 78 
> +++-
>  drivers/gpu/drm/i915/i915_gem_clflush.c  | 15 +++--
>  drivers/gpu/drm/i915/i915_gem_execbuffer.c   | 21 +++
>  drivers/gpu/drm/i915/i915_gem_internal.c |  3 +-
>  drivers/gpu/drm/i915/i915_gem_userptr.c  |  5 +-
>  drivers/gpu/drm/i915/selftests/huge_gem_object.c |  3 +-
>  6 files changed, 70 insertions(+), 55 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 33fb11cc5acc..488ca7733c1e 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -49,7 +49,7 @@ static void i915_gem_flush_free_objects(struct 
> drm_i915_private *i915);
>  
>  static bool cpu_write_needs_clflush(struct drm_i915_gem_object *obj)
>  {
> - if (obj->base.write_domain == I915_GEM_DOMAIN_CPU)
> + if (obj->cache_dirty)
>   return false;
>  
>   if (!i915_gem_object_is_coherent(obj))
> @@ -233,6 +233,14 @@ i915_gem_object_get_pages_phys(struct 
> drm_i915_gem_object *obj)
>   return st;
>  }
>  
> +static void __start_cpu_write(struct drm_i915_gem_object *obj)
> +{
> + obj->base.read_domains = I915_GEM_DOMAIN_CPU;
> + obj->base.write_domain = I915_GEM_DOMAIN_CPU;
> + if (cpu_write_needs_clflush(obj))
> + obj->cache_dirty = true;
> +}
> +
>  static void
>  __i915_gem_object_release_shmem(struct drm_i915_gem_object *obj,
>   struct sg_table *pages,
> @@ -248,8 +256,7 @@ __i915_gem_object_release_shmem(struct 
> drm_i915_gem_object *obj,
>   !i915_gem_object_is_coherent(obj))
>   drm_clflush_sg(pages);
>  
> - obj->base.read_domains = I915_GEM_DOMAIN_CPU;
> - obj->base.write_domain = I915_GEM_DOMAIN_CPU;
> + __start_cpu_write(obj);
>  }
>  
>  static void
> @@ -684,6 +691,12 @@ i915_gem_dumb_create(struct drm_file *file,
>  args->size, &args->handle);
>  }
>  
> +static bool gpu_write_needs_clflush(struct drm_i915_gem_object *obj)
> +{
> + return !(obj->cache_level == I915_CACHE_NONE ||
> +  obj->cache_level == I915_CACHE_WT);
> +}
> +
>  /**
>   * Creates a new mm object and returns a handle to it.
>   * @dev: drm device pointer
> @@ -753,6 +766,11 @@ flush_write_domain(struct drm_i915_gem_object *obj, 
> unsigned int flush_domains)
>   case I915_GEM_DOMAIN_CPU:
>   i915_gem_clflush_object(obj, I915_CLFLUSH_SYNC);
>   break;
> +
> + case I915_GEM_DOMAIN_RENDER:
> + if (gpu_write_needs_clflush(obj))
> + obj->cache_dirty = true;
> + break;
>   }
>  
>   obj->base.write_domain = 0;
> @@ -854,7 +872,8 @@ int i915_gem_obj_prepare_shmem_read(struct 
> drm_i915_gem_object *obj,
>* optimizes for the case when t

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Reset hangcheck timeouts upon idling

[Chris Wilson]

On Wed, Apr 19, 2017 at 05:09:46PM +0300, Mika Kuoppala wrote:
> Chris Wilson  writes:
> 
> > If we have a long period of idleness, we turn off the hangcheck timer
> > and stop polling the hardware. Before we restart the hangcheck, we
> > should clear the previous timestamps to prevent us thinking that the
> > engine was stalled for a long time, if the seqno were manipulated
> > carefully (such as the repeating patterns in gem_exec_whisper).
> >
> > It should have no impact upon normal use.
> >
> > Signed-off-by: Chris Wilson 
> > Cc: Mika Kuoppala 
> > ---
> >  drivers/gpu/drm/i915/intel_hangcheck.c | 14 ++
> >  1 file changed, 10 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_hangcheck.c 
> > b/drivers/gpu/drm/i915/intel_hangcheck.c
> > index b0ca0c4c70d9..a74decca5109 100644
> > --- a/drivers/gpu/drm/i915/intel_hangcheck.c
> > +++ b/drivers/gpu/drm/i915/intel_hangcheck.c
> > @@ -409,13 +409,13 @@ static void i915_hangcheck_elapsed(struct work_struct 
> > *work)
> > int busy_count = 0;
> >  
> > if (!i915.enable_hangcheck)
> > -   return;
> > +   goto disarm_hangcheck;
> >  
> > if (!READ_ONCE(dev_priv->gt.awake))
> > -   return;
> > +   goto disarm_hangcheck;
> >  
> > if (i915_terminally_wedged(&dev_priv->gpu_error))
> > -   return;
> > +   goto disarm_hangcheck;
> >  
> > /* As enabling the GPU requires fairly extensive mmio access,
> >  * periodically arm the mmio checker to see if we are triggering
> > @@ -446,8 +446,14 @@ static void i915_hangcheck_elapsed(struct work_struct 
> > *work)
> > hangcheck_declare_hang(dev_priv, hung, stuck);
> >  
> > /* Reset timer in case GPU hangs without another request being added */
> > -   if (busy_count)
> > +   if (busy_count) {
> > i915_queue_hangcheck(dev_priv);
> 
> Now if we don't have a waiter, we always init hangcheck. And thus
> we never detect a hang if so. As demonstrated by the
> gem_busy@basic-default-hang.
> 
> I suggest we decouple the waiters completely from hangcheck:
> 
> -   const bool busy = intel_engine_has_waiter(engine);
> +   const bool busy = engine->timeline->inflight_seqnos;

inflight seqnos isn't a good choice either, as that doesn't mean the
engine is active yet. The only issue with this patch was resetting the
hangcheck.seqno nerfed the waiterless hangcheck. Turned out to be a very
bad idea.
-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 v6 1/3] ACPI / bus: Introduce a list of ids for "always present" devices

[Lukas Wunner]

On Wed, Apr 19, 2017 at 12:28:50PM +0200, Rafael J. Wysocki wrote:
> On Wed, Apr 19, 2017 at 10:59 AM, Hans de Goede  wrote:
> > On 18-04-17 15:34, Rafael J. Wysocki wrote:
> >> On Tue, Apr 18, 2017 at 1:54 PM, Hans de Goede  wrote:
> >>>
> >>> Several Cherry Trail devices (all of which ship with Windows 10) hide the
> >>> LPSS PWM controller in ACPI, typically the _STA method looks like this:
> >>>
> >>> Method (_STA, 0, NotSerialized)  // _STA: Status
> >>> {
> >>> If (OSID == One)
> >>> {
> >>> Return (Zero)
> >>> }
> >>>
> >>> Return (0x0F)
> >>> }
> >>>
> >>> Where OSID is some dark magic seen in all Cherry Trail ACPI tables making
> >>> the machine behave differently depending on which OS it *thinks* it is
> >>> booting, this gets set in a number of ways which we cannot control, on
> >>> some newer machines it simple hardcoded to "One" aka win10.
> >>>
> >>> This causes the PWM controller to get hidden, which means Linux cannot
> >>> control the backlight level on cht based tablets / laptops.
> >>>
> >>> Since loading the driver for this does no harm (the only in kernel user
> >>> of it is the i915 driver, which will only use it when it needs it), this
> >>> commit makes acpi_bus_get_status() always set status to ACPI_STA_DEFAULT
> >>> for the 80862288 device, fixing the lack of backlight control.
> >>>
> >>> Signed-off-by: Hans de Goede 
> >>> ---
> >>>  drivers/acpi/bus.c  | 65
> >>> +
> >>>  include/acpi/acpi_bus.h |  6 +
> >>>  2 files changed, 66 insertions(+), 5 deletions(-)
> >>>
> >>> diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
> >>> index 34fbe02..eb30630 100644
> >>> --- a/drivers/acpi/bus.c
> >>> +++ b/drivers/acpi/bus.c
> >>> @@ -34,6 +34,8 @@
> >>>  #include 
> >>>  #include 
> >>>  #ifdef CONFIG_X86
> >>> +#include 
> >>> +#include 
> >>>  #include 
> >>>  #endif
> >>>  #include 
> >>> @@ -132,6 +134,69 @@ int acpi_bus_get_status(struct acpi_device *device)
> >>>  }
> >>>  EXPORT_SYMBOL(acpi_bus_get_status);
> >>>
> >>> +#ifdef CONFIG_X86
> >>> +/*
> >>> + * Some ACPI devices are hidden (status == 0x0) in recent BIOS-es
> >>> because
> >>> + * some recent Windows drivers bind to one device but poke at multiple
> >>> + * devices at the same time, so the others get hidden.
> >>> + * We work around this by always reporting ACPI_STA_DEFAULT for these
> >>> + * devices. Note this MUST only be done for devices where this is safe.
> >>> + *
> >>> + * This forcing of devices to be present is limited to specific CPU
> >>> (SoC)
> >>> + * models both to avoid potentially causing trouble on other models and
> >>> + * because some HIDs are re-used on different SoCs for completely
> >>> + * different devices.
> >>> + */
> >>> +struct always_present_device_id {
> >>> +   struct acpi_device_id hid[2];
> >>> +   struct x86_cpu_id cpu_ids[2];
> >>
> >> This really is x86-specific, so it should go into somewhere like
> >> arch/x86/kernel/acpi/ or drivers/acpi/x86/ (not present yet).
> >
> > Ok, but then how do you want to hook this up, before you said
> > that you wanted to deal with this in acpi_set_device_status(),
> > which belongs in drivers/acpi/bus.c, do you want the x86
> > code to provide something like a
> >
> > bool acpi_device_always_present(struct acpi_device *adev) {
> > }
> >
> > Helper function and use that in the drivers/acpi/bus.c
> > acpi_set_device_status() implementation ?
> 
> Yes, something like that.
> 
> In a header file you can make it depend on CONFIG_X86 and provide and
> empty static inline stub for the "not defined" case.

The PCI subsystem uses __weak stubs such as pcibios_add_bus() for arch-
specific behaviour, or quirks which can be declared in arch/x86 to
constrain them to this specific platform.

Perhaps it makes sense to introduce ACPI quirks which can be declared
the same way as PCI quirks to avoid cluttering the generic code with
arch- or device-specific special cases.  So in this case we'd have
something like:

DECLARE_ACPI_FIXUP_STATUS(const char *hid, const char *uid, hook);

And before calling _STA we'd check for presence of a fixup for the
device in question.  Any additional stuff such as _HRV, CPU ID,
DMI data could be checked in the fixup hook.  Thoughts?

By the way:

> >>> +void acpi_set_device_status(struct acpi_device *adev, u32 sta)
> >>> +{
> >>> +   u32 *status = (u32 *)&adev->status;
> >>> +#ifdef CONFIG_X86
> >>> +   u32 old_status = *status;
> >>> +   int i;
> >>> +
> >>> +   /* acpi_match_device_ids checks status, so start with default */
> >>> +   *status = ACPI_STA_DEFAULT;
> >>> +   for (i = 0; i < ARRAY_SIZE(always_present_device_ids); i++) {
> >>> +   if (acpi_match_device_ids(adev,
> >>> +   always_present_device_ids[i].hid) == 0 &&
> >>> +   adev->pnp.unique_id &&
> >>> +   strcmp(adev->pnp.unique_id,
> >>> +  

Re: [Intel-gfx] [PATCH 04/11] drm: parse ycbcr420 vcb block

[Sharma, Shashank]

Regards

Shashank


On 4/8/2017 11:13 PM, Emil Velikov wrote:

Hi Shashank,

On 7 April 2017 at 17:39, Shashank Sharma  wrote:


+   u64 hdmi_420_cap_map = connector->display_info.hdmi.ycbcr420_vcb_map;

 for (i = 0; i < len; i++) {
 struct drm_display_mode *mode;
 mode = drm_display_mode_from_vic_index(connector, db, len, i);
 if (mode) {
+   /*
+* ycbcr420 capability block contains a bitmap which
+* gives the index of such CEA modes in VDB, which can
+* support ycbcr420 sampling output also.
+* For example, if the bit 0 in bitmap is set,
+* first mode in VDB can support ycbcr420 output too.
+*/
+   if (hdmi_420_cap_map & (1 << i))

Since map is u64 you really want to use something like (1ull << i)
here. Otherwise you'll get a 32 bit value, regardless of i.

Thanks Emil, this was a good catch.



+   for (count = 0; count < map_len; count++)
+   map = (db[2 + count] << 8 * count) | map;
+

The above issue is applicable here as well. With a small nitpick the
whole thing will read

map |= (u64)db[2 + count] << (8 * count);

Agree, thanks.



--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -136,6 +136,7 @@ struct drm_scdc {
  struct drm_hdmi_info {
 /** @scdc: sink's scdc support and capabilities */
 struct drm_scdc scdc;
+   u64 ycbcr420_vcb_map;

As pointed by the kbuild robot - you really want to document the field.

Agree, will handle this in next patch set.

Regards,
Emil


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

Re: [Intel-gfx] [PATCH 01/11] drm: Add HDMI 2.0 VIC support for AVI info-frames

[Sharma, Shashank]

Regards

Shashank


On 4/10/2017 3:17 PM, Andrzej Hajda wrote:

On 07.04.2017 18:39, Shashank Sharma wrote:

HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
For any other mode, the VIC filed in AVI infoframes should be 0.
HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
extended to (VIC 1-107).

This patch adds a bool input variable, which indicates if the connected
sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a
HDMI 2.0 VIC to a HDMI 1.4 sink.

This patch touches all drm drivers, who are callers of this function
drm_hdmi_avi_infoframe_from_display_mode but to make sure there is
no change in current behavior, is_hdmi2 is kept as false.

In case of I915 driver, this patch checks the connector->display_info
to check if the connected display is HDMI 2.0.

Cc: Ville Syrjala 
Cc: Jose Abreu 
Cc: Andrzej Hajda 
Cc: Alex Deucher 
Cc: Daniel Vetter 

PS: This patch touches a few lines in few files, which were
already above 80 char, so checkpatch gives 80 char warning again.
- gpu/drm/omapdrm/omap_encoder.c
- gpu/drm/i915/intel_sdvo.c

Signed-off-by: Shashank Sharma 

Finally I have chances to look at the specs and I am not sure if this
solution fully reflects the specs and is scalable. According to specs
VIC set to 0 in AVIF means "Video Format not documented in CTA-861", ie
it is described by vendor specific data block and vendor specific
infoframe, maybe something else(???).

It says "Video Format not documented in CEA-861 (means this version)"

I suppose ideally during EDID read
there should be recorded info for every mode if it was defined by vendor
extension, or not. This info could be later used by drivers to configure
AVIF and VSIF accordingly.
I don't think this has to do anything with it, we are simply checking if 
the monitor is HDMI 2.0 capable,
coz if it is, it would be complaint to CEA-861-F and it would understand 
the VIC>64. If not && VIC>64, we will send
VIC as 0, coz this VIC is defined in CEA-861-F spec. So I don't see the 
confusion.


You are welcome to suggest, how can we make it more scalable, or improve 
on it. We can always send revised patch set :-)


- Shashank


Anyway as a short-term initial solution it could work.
So:
Reviewed-by: Andrzej Hajda 

  --
Regards
Andrzej


---
  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|  2 +-
  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|  2 +-
  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |  2 +-
  drivers/gpu/drm/bridge/analogix-anx78xx.c |  3 ++-
  drivers/gpu/drm/bridge/sii902x.c  |  2 +-
  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  2 +-
  drivers/gpu/drm/drm_edid.c| 12 +++-
  drivers/gpu/drm/exynos/exynos_hdmi.c  |  2 +-
  drivers/gpu/drm/i2c/tda998x_drv.c |  2 +-
  drivers/gpu/drm/i915/intel_hdmi.c |  5 -
  drivers/gpu/drm/i915/intel_sdvo.c |  3 ++-
  drivers/gpu/drm/mediatek/mtk_hdmi.c   |  2 +-
  drivers/gpu/drm/omapdrm/omap_encoder.c|  3 ++-
  drivers/gpu/drm/radeon/radeon_audio.c |  2 +-
  drivers/gpu/drm/rockchip/inno_hdmi.c  |  2 +-
  drivers/gpu/drm/sti/sti_hdmi.c|  2 +-
  drivers/gpu/drm/tegra/hdmi.c  |  2 +-
  drivers/gpu/drm/tegra/sor.c   |  2 +-
  drivers/gpu/drm/vc4/vc4_hdmi.c|  2 +-
  drivers/gpu/drm/zte/zx_hdmi.c |  2 +-
  include/drm/drm_edid.h|  3 ++-
  21 files changed, 38 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
index daf003d..5dc3e95 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
@@ -1877,7 +1877,7 @@ static void dce_v10_0_afmt_setmode(struct drm_encoder 
*encoder,
dce_v10_0_audio_write_sad_regs(encoder);
dce_v10_0_audio_write_latency_fields(encoder, mode);
  
-	err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);

+   err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
if (err < 0) {
DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
return;
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
index 3a72967..b70f077 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
@@ -1861,7 +1861,7 @@ static void dce_v11_0_afmt_setmode(struct drm_encoder 
*encoder,
dce_v11_0_audio_write_sad_regs(encoder);
dce_v11_0_audio_write_latency_fields(encoder, mode);
  
-	err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);

+   err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
if (err < 0) {
DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
return;
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
index 6943f26..bcf9c75 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
+++ b

Re: [Intel-gfx] [PATCH v4 9/9] drm/i915: Convert intel_sdvo connector properties to atomic.

[Daniel Vetter]

On Wed, Apr 12, 2017 at 12:50:07PM +0200, Maarten Lankhorst wrote:
> SDVO was the last connector that's still using the legacy paths
> for properties, and this is with a reason!
> 
> This connector implements a lot of properties dynamically,
> and some of them shared with the digital connector state,
> so sdvo_connector_state subclasses intel_digital_connector_state.
> 
> set_property had a lot of validation, but this is handled in the
> drm core, so most of the validation can die off. The properties
> are written right before enabling the connector, since there is no
> good way to update the properties without crtc.
> 
> Signed-off-by: Maarten Lankhorst 

Yeah, somewhat silly that we can't just reuse the core decoding for all of
these, but oh well. For the series, except where I dropped some comments

Reviewed-by: Daniel Vetter 

For the others r-b once those comments are addressed, I don't expect a
huge impact on those (e.g. as long as we register the scaling property
from within panel_init you can keep the allowed_pfit_mode_mask stuff
you're adding here).
-Daniel


> ---
>  drivers/gpu/drm/i915/intel_atomic.c  |  40 ---
>  drivers/gpu/drm/i915/intel_display.c |  37 ---
>  drivers/gpu/drm/i915/intel_drv.h |   6 -
>  drivers/gpu/drm/i915/intel_sdvo.c| 538 
> ++-
>  4 files changed, 281 insertions(+), 340 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
> b/drivers/gpu/drm/i915/intel_atomic.c
> index eb72166675f0..f068b623cf10 100644
> --- a/drivers/gpu/drm/i915/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> @@ -36,46 +36,6 @@
>  #include "intel_drv.h"
>  
>  /**
> - * intel_connector_atomic_get_property - fetch legacy connector property 
> value
> - * @connector: connector to fetch property for
> - * @state: state containing the property value
> - * @property: property to look up
> - * @val: pointer to write property value into
> - *
> - * The DRM core does not store shadow copies of properties for
> - * atomic-capable drivers.  This entrypoint is used to fetch
> - * the current value of a driver-specific connector property.
> - *
> - * This is a intermediary solution until all connectors are
> - * converted to support full atomic properties.
> - */
> -int intel_connector_atomic_get_property(struct drm_connector *connector,
> - const struct drm_connector_state *state,
> - struct drm_property *property,
> - uint64_t *val)
> -{
> - int i;
> -
> - /*
> -  * TODO: We only have atomic modeset for planes at the moment, so the
> -  * crtc/connector code isn't quite ready yet.  Until it's ready,
> -  * continue to look up all property values in the DRM's shadow copy
> -  * in obj->properties->values[].
> -  *
> -  * When the crtc/connector state work matures, this function should
> -  * be updated to read the values out of the state structure instead.
> -  */
> - for (i = 0; i < connector->base.properties->count; i++) {
> - if (connector->base.properties->properties[i] == property) {
> - *val = connector->base.properties->values[i];
> - return 0;
> - }
> - }
> -
> - return -EINVAL;
> -}
> -
> -/**
>   * intel_digital_connector_atomic_get_property - hook for 
> connector->atomic_get_property.
>   * @connector: Connector to get the property for.
>   * @state: Connector state to retrieve the property from.
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 5eb4ddb04797..c2c367b90c0a 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13075,43 +13075,6 @@ static int intel_atomic_commit(struct drm_device 
> *dev,
>   return 0;
>  }
>  
> -void intel_crtc_restore_mode(struct drm_crtc *crtc)
> -{
> - struct drm_device *dev = crtc->dev;
> - struct drm_atomic_state *state;
> - struct drm_crtc_state *crtc_state;
> - int ret;
> -
> - state = drm_atomic_state_alloc(dev);
> - if (!state) {
> - DRM_DEBUG_KMS("[CRTC:%d:%s] crtc restore failed, out of memory",
> -   crtc->base.id, crtc->name);
> - return;
> - }
> -
> - state->acquire_ctx = crtc->dev->mode_config.acquire_ctx;
> -
> -retry:
> - crtc_state = drm_atomic_get_crtc_state(state, crtc);
> - ret = PTR_ERR_OR_ZERO(crtc_state);
> - if (!ret) {
> - if (!crtc_state->active)
> - goto out;
> -
> - crtc_state->mode_changed = true;
> - ret = drm_atomic_commit(state);
> - }
> -
> - if (ret == -EDEADLK) {
> - drm_atomic_state_clear(state);
> - drm_modeset_backoff(state->acquire_ctx);
> - goto retry;
> - }
> -
> -out:
> - drm_atomic_state_put(state);
> -}
> -
>  static const struct drm_crtc_

Re: [Intel-gfx] [PATCH 07/11] drm: set output colorspace in AVI infoframe

[Sharma, Shashank]

Regards

Shashank


On 4/12/2017 3:19 PM, Jose Abreu wrote:

Hi Shashank,


On 07-04-2017 17:39, Shashank Sharma wrote:

HDMI source must set output colorspace information in AVI
infoframes, so that the sink can decode upcoming frames
accordingly.

As this patch series is adding support for HDMI output modes
other than RGB, this patch adds a function in DRM layer, to
add the output colorspace information in the AVI infoframes.

Cc: Ville Syrjala 
Cc: Jose Abreu 
Signed-off-by: Shashank Sharma 
---
  drivers/gpu/drm/drm_edid.c | 40 
  include/drm/drm_edid.h |  5 +
  2 files changed, 45 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 828b781..a02d35b 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4734,6 +4734,46 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
hdmi_avi_infoframe *frame,
  EXPORT_SYMBOL(drm_hdmi_avi_infoframe_from_display_mode);
  
  /**

+ * drm_hdmi_avi_infoframe_set_colorspace() - fill an HDMI AVI infoframe with
+ * colorspace data of the output type
+ *
+ * @frame: HDMI AVI infoframe
+ * @mode: DRM display mode
+ * @hdmi_output: HDMI output colorspace
+ *
+ * Return: 0 on success or a negative error code on failure.
+ */
+int
+drm_hdmi_avi_infoframe_set_colorspace(struct hdmi_avi_infoframe *frame,
+const struct drm_display_mode *mode,
+enum drm_hdmi_output_type hdmi_output)
+{
+   switch (hdmi_output) {
+   case DRM_HDMI_OUTPUT_YCBCR444:
+   frame->colorspace = HDMI_COLORSPACE_YUV444;
+   break;
+   case DRM_HDMI_OUTPUT_YCBCR422:
+   frame->colorspace = HDMI_COLORSPACE_YUV422;
+   break;
+   case DRM_HDMI_OUTPUT_YCBCR420:
+   frame->colorspace = HDMI_COLORSPACE_YUV420;
+   frame->pixel_repeat = 0;

Why only 4:2:0 is set with pixel repetition off? Is this per spec?
Yes, the HDMI 2.0/CEA-861-F mandates the source to turn off pixel 
repetition for YCBCR420 output.

+   break;
+   case DRM_HDMI_OUTPUT_DEFAULT_RGB:
+   frame->colorspace = HDMI_COLORSPACE_RGB;
+   break;
+   case DRM_HDMI_OUTPUT_YCBCR_HQ:
+   case DRM_HDMI_OUTPUT_YCBCR_LQ:
+   case DRM_HDMI_OUTPUT_INVALID:

Maybe default to RGB here? I don't know if spec says anything
about sending empty colorspace field.
Actually, by default the enum value for RGB is 0, that's why we were not 
setting this field at all, as there was only RGB output.
case HQ/LQ indicate that user wanted to have YCBCR output (but it should 
have never reached this point), so I am not sure if its

good idea to default to RGB, or is it :) ? lets hear from others too.

- Shashank

Best regards,
Jose Miguel Abreu


+   DRM_ERROR("Invalid HDMI output type\n");
+   return -EINVAL;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_hdmi_avi_infoframe_set_colorspace);
+
+/**
   * drm_hdmi_avi_infoframe_quant_range() - fill the HDMI AVI infoframe
   *quantization range information
   * @frame: HDMI AVI infoframe
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index a4d174e7..8980366 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -329,6 +329,7 @@ struct cea_sad {
  struct drm_encoder;
  struct drm_connector;
  struct drm_display_mode;
+enum drm_hdmi_output_type;
  
  void drm_edid_to_eld(struct drm_connector *connector, struct edid *edid);

  int drm_edid_to_sad(struct edid *edid, struct cea_sad **sads);
@@ -351,6 +352,10 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
hdmi_avi_infoframe *frame,
 const struct drm_display_mode *mode,
 bool is_hdmi2);
  int
+drm_hdmi_avi_infoframe_set_colorspace(struct hdmi_avi_infoframe *frame,
+const struct drm_display_mode *mode,
+enum drm_hdmi_output_type hdmi_output);
+int
  drm_hdmi_vendor_infoframe_from_display_mode(struct hdmi_vendor_infoframe 
*frame,
const struct drm_display_mode 
*mode);
  void


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

Re: [Intel-gfx] [PATCH v4 6/9] drm/i915: Convert intel_dp properties to atomic.

[Daniel Vetter]

On Wed, Apr 12, 2017 at 12:50:04PM +0200, Maarten Lankhorst wrote:
> intel_dp supports 3 properties, scaling mode, broadcast rgb and
> force_audio. intel_digital_connector handles the plumbing,
> so we only have to hook this up in compute_config and init.
> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/intel_dp.c  | 136 
> +++
>  drivers/gpu/drm/i915/intel_drv.h |   3 -
>  2 files changed, 24 insertions(+), 115 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index b1a0cb3c79d4..f976d10b4f0a 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1630,6 +1630,8 @@ intel_dp_compute_config(struct intel_encoder *encoder,
>   enum port port = dp_to_dig_port(intel_dp)->port;
>   struct intel_crtc *intel_crtc = to_intel_crtc(pipe_config->base.crtc);
>   struct intel_connector *intel_connector = intel_dp->attached_connector;
> + struct intel_digital_connector_state *intel_conn_state =
> + to_intel_digital_connector_state(conn_state);
>   int lane_count, clock;
>   int min_lane_count = 1;
>   int max_lane_count = intel_dp_max_lane_count(intel_dp);
> @@ -1655,10 +1657,10 @@ intel_dp_compute_config(struct intel_encoder *encoder,
>   pipe_config->has_drrs = false;
>   if (port == PORT_A)
>   pipe_config->has_audio = false;
> - else if (intel_dp->force_audio == HDMI_AUDIO_AUTO)
> + else if (intel_conn_state->force_audio == HDMI_AUDIO_AUTO)
>   pipe_config->has_audio = intel_dp->has_audio;
>   else
> - pipe_config->has_audio = intel_dp->force_audio == HDMI_AUDIO_ON;
> + pipe_config->has_audio = intel_conn_state->force_audio == 
> HDMI_AUDIO_ON;
>  
>   if (is_edp(intel_dp) && intel_connector->panel.fixed_mode) {
>   intel_fixed_panel_mode(intel_connector->panel.fixed_mode,
> @@ -1673,10 +1675,10 @@ intel_dp_compute_config(struct intel_encoder *encoder,
>  
>   if (HAS_GMCH_DISPLAY(dev_priv))
>   intel_gmch_panel_fitting(intel_crtc, pipe_config,
> -  
> intel_connector->panel.fitting_mode);
> +  conn_state->scaling_mode);
>   else
>   intel_pch_panel_fitting(intel_crtc, pipe_config,
> - 
> intel_connector->panel.fitting_mode);
> + conn_state->scaling_mode);
>   }
>  
>   if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK)
> @@ -1745,7 +1747,7 @@ intel_dp_compute_config(struct intel_encoder *encoder,
>   return false;
>  
>  found:
> - if (intel_dp->color_range_auto) {
> + if (intel_conn_state->broadcast_rgb == INTEL_BROADCAST_RGB_AUTO) {
>   /*
>* See:
>* CEA-861-E - 5.1 Default Encoding Parameters
> @@ -1757,7 +1759,7 @@ intel_dp_compute_config(struct intel_encoder *encoder,
>   HDMI_QUANTIZATION_RANGE_LIMITED;
>   } else {
>   pipe_config->limited_color_range =
> - intel_dp->limited_color_range;
> + intel_conn_state->broadcast_rgb == 
> INTEL_BROADCAST_RGB_LIMITED;
>   }
>  
>   pipe_config->lane_count = lane_count;
> @@ -4781,104 +4783,6 @@ static int intel_dp_get_modes(struct drm_connector 
> *connector)
>  }
>  
>  static int
> -intel_dp_set_property(struct drm_connector *connector,
> -   struct drm_property *property,
> -   uint64_t val)
> -{
> - struct drm_i915_private *dev_priv = to_i915(connector->dev);
> - struct intel_connector *intel_connector = to_intel_connector(connector);
> - struct intel_encoder *intel_encoder = intel_attached_encoder(connector);
> - struct intel_dp *intel_dp = enc_to_intel_dp(&intel_encoder->base);
> - int ret;
> -
> - ret = drm_object_property_set_value(&connector->base, property, val);
> - if (ret)
> - return ret;
> -
> - if (property == dev_priv->force_audio_property) {
> - int i = val;
> - bool has_audio, old_has_audio;
> - int old_force_audio = intel_dp->force_audio;
> -
> - if (i == intel_dp->force_audio)
> - return 0;
> -
> - if (old_force_audio == HDMI_AUDIO_AUTO)
> - old_has_audio = intel_dp->has_audio;
> - else
> - old_has_audio = old_force_audio;
> -
> - intel_dp->force_audio = i;
> -
> - if (i == HDMI_AUDIO_AUTO)
> - has_audio = intel_dp->has_audio;
> - else
> - has_audio = (i == HDMI_AUDIO_ON);
> -
> - if (has_audio == old_has_audio)
> - return 0;
> -
> - goto done;
> - }
> -
> - if (property == dev_pri

Re: [Intel-gfx] [PATCH 06/11] drm: create hdmi output property

[Sharma, Shashank]

Hello Jose,

Sorry for delay in response, I was on vacation.
Please find my comments inline.

Regards
Shashank
On 4/12/2017 3:28 PM, Jose Abreu wrote:

Hi Shashank,


On 07-04-2017 17:39, Shashank Sharma wrote:

HDMI displays can support various output types, based on
the color space and subsampling type. The possible
outputs from a HDMI 2.0 monitor could be:
  - RGB
  - YCBCR 444
  - YCBCR 422
  - YCBCR 420

This patch adds a drm property, using which, a userspace
can specify its preference, for the HDMI output type.
The output type enums are similar to the mentioned outputs
above. To handle various subsampling of YCBCR output types,
this property allows two special cases:
  - DRM_HDMI_OUTPUT_YCBCR_HQ
This indicates preferred output should be YCBCR output, with highest
subsampling rate by the source/sink, which can be typically:
  - ycbcr444
  - ycbcr422
  - ycbcr420
  - DRM_HDMI_OUTPUT_YCBCR_LQ
This indicates preferred output should be YCBCR output, with lowest
subsampling rate supported by source/sink, which can be:
  - ycbcr420
  - ycbcr422
  - ycbcr444

Default value of the property is set to 0 = RGB, so no changes if you
dont set the property.

The HQ/LQ properties are a nice idea

Courtesy Ville :)

but where are you parsing
them (because in patch 07/11 you reject these properties)? Also,
you need to make sure that source and sink supports the color space.
Yes, and that's why its handling is kept in the core driver. If you see 
my I915 patches, I have parsed and handled the HQ and LQ properties in
intel_hdmi_compute_ycbcr_config function. I am rejecting the HQ/LQ in 
07/11, coz by the time we want to set AVI_IF the driver should have picked
the highest/lowest YCBCR mode, and now we should have a definite one out 
of 444,422 or 420.


Do you think it would be a good idea to find the HQ/LQ YCBCR output in 
DRM layer ? In that case it would be difficult if source supports these 
outputs


- Shashank

Best regards,
Jose Miguel Abreu


Cc: Ville Syrjala 
Cc: Jose Abreu 
Cc: Daniel Vetter 
Signed-off-by: Shashank Sharma 
---
  drivers/gpu/drm/drm_atomic.c|  2 ++
  drivers/gpu/drm/drm_atomic_helper.c |  4 
  drivers/gpu/drm/drm_connector.c | 31 +++
  include/drm/drm_connector.h | 14 ++
  include/drm/drm_mode_config.h   |  5 +
  5 files changed, 56 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index f32506a..6ef34dc 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1123,6 +1123,8 @@ int drm_atomic_connector_set_property(struct 
drm_connector *connector,
 */
if (state->link_status != DRM_LINK_STATUS_GOOD)
state->link_status = val;
+   } else if (property == config->hdmi_output_property) {
+   state->hdmi_output = val;
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(connector,
state, property, val);
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 8be9719..fcba3c0 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -567,6 +567,10 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
if (old_connector_state->link_status !=
new_connector_state->link_status)
new_crtc_state->connectors_changed = true;
+
+   if (old_connector_state->hdmi_output !=
+   new_connector_state->hdmi_output)
+   new_crtc_state->connectors_changed = true;
}
  
  		if (funcs->atomic_check)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 9f84761..10201b1 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -227,6 +227,11 @@ int drm_connector_init(struct drm_device *dev,
  config->edid_property,
  0);
  
+	if (connector_type != DRM_MODE_CONNECTOR_VIRTUAL)

+   drm_object_attach_property(&connector->base,
+  config->hdmi_output_property,
+  0);
+
drm_object_attach_property(&connector->base,
  config->dpms_property, 0);
  
@@ -617,6 +622,25 @@ static const struct drm_prop_enum_list drm_link_status_enum_list[] = {

  };
  DRM_ENUM_NAME_FN(drm_get_link_status_name, drm_link_status_enum_list)
  
+static const struct drm_prop_enum_list drm_hdmi_output_enum_list[] = {

+   { DRM_HDMI_OUTPUT_DEFAULT_RGB, "output_rgb" },
+   { DRM_HDMI_OUTPUT_YCBCR422, "output_ycbcr422" },
+   { DRM_HDMI_OUTPUT_YCBCR444, "output_ycbcr444" },
+   { DRM_HDMI_OUTPUT_YCBCR420, "output_ycbcr

Re: [Intel-gfx] [PATCH v4 2/9] drm/i915: Add plumbing for digital connector state, v2.

[Daniel Vetter]

On Wed, Apr 12, 2017 at 12:50:00PM +0200, Maarten Lankhorst wrote:
> Some atomic properties are common between the various kinds of
> connectors, for example a lot of them use panel fitting mode.
> It makes sense to put a lot of it in a common place, so each
> connector can use it while they're being converted.
> 
> Implement the properties required for the connectors:
> - scaling mode property
> - force audio property
> - broadcast rgb
> - aspect ratio
> 
> While at it, make clear that intel_digital_connector_atomic_get_property
> is a hack that has to be removed when all connector properties
> are converted to atomic.
> 
> Changes since v1:
> - Scaling mode and aspect ratio are partly handled in core now.
> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/intel_atomic.c  | 142 
> +--
>  drivers/gpu/drm/i915/intel_display.c |  14 +++-
>  drivers/gpu/drm/i915/intel_dp.c  |   2 +-
>  drivers/gpu/drm/i915/intel_drv.h |  27 ++-
>  drivers/gpu/drm/i915/intel_dsi.c |   2 +-
>  drivers/gpu/drm/i915/intel_dvo.c |   2 +-
>  drivers/gpu/drm/i915/intel_lvds.c|   2 +-
>  drivers/gpu/drm/i915/intel_panel.c   |   4 +-
>  8 files changed, 180 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
> b/drivers/gpu/drm/i915/intel_atomic.c
> index 50fb1f76cc5f..eb72166675f0 100644
> --- a/drivers/gpu/drm/i915/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/intel_atomic.c

Refactoring idea for the future: intel_atomic.c makes 0 sense, just makes
sure we have lots of functionality spread all over imo. I think following
the split-up model I've done in the drm core would be a lot better, with
intel_connector/encoder/crtc/plane.c for the shared helper functions. And
then maybe separate files for the per-platform stuff, e.g. i9xx_crtc.c,
pch_crtc.c and so on.

> @@ -36,7 +36,7 @@
>  #include "intel_drv.h"
>  
>  /**
> - * intel_connector_atomic_get_property - fetch connector property value
> + * intel_connector_atomic_get_property - fetch legacy connector property 
> value
>   * @connector: connector to fetch property for
>   * @state: state containing the property value
>   * @property: property to look up
> @@ -45,12 +45,14 @@
>   * The DRM core does not store shadow copies of properties for
>   * atomic-capable drivers.  This entrypoint is used to fetch
>   * the current value of a driver-specific connector property.
> + *
> + * This is a intermediary solution until all connectors are
> + * converted to support full atomic properties.
>   */
> -int
> -intel_connector_atomic_get_property(struct drm_connector *connector,
> - const struct drm_connector_state *state,
> - struct drm_property *property,
> - uint64_t *val)
> +int intel_connector_atomic_get_property(struct drm_connector *connector,
> + const struct drm_connector_state *state,
> + struct drm_property *property,
> + uint64_t *val)
>  {
>   int i;
>  
> @@ -73,7 +75,133 @@ intel_connector_atomic_get_property(struct drm_connector 
> *connector,
>   return -EINVAL;
>  }
>  
> -/*
> +/**
> + * intel_digital_connector_atomic_get_property - hook for 
> connector->atomic_get_property.
> + * @connector: Connector to get the property for.
> + * @state: Connector state to retrieve the property from.
> + * @property: Property to retrieve.
> + * @val: Return value for the property.
> + *
> + * Returns the atomic property value for a digital connector.
> + */
> +int intel_digital_connector_atomic_get_property(struct drm_connector 
> *connector,
> + const struct 
> drm_connector_state *state,
> + struct drm_property *property,
> + uint64_t *val)
> +{
> + struct drm_device *dev = connector->dev;
> + struct drm_i915_private *dev_priv = to_i915(dev);
> + struct intel_digital_connector_state *intel_conn_state =
> + to_intel_digital_connector_state(state);
> +
> + if (property == dev_priv->force_audio_property)
> + *val = intel_conn_state->force_audio;
> + else if (property == dev_priv->broadcast_rgb_property)
> + *val = intel_conn_state->broadcast_rgb;
> + else {
> + DRM_DEBUG_ATOMIC("Unknown property %s\n", property->name);
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +/**
> + * intel_digital_connector_atomic_set_property - hook for 
> connector->atomic_set_property.
> + * @connector: Connector to set the property for.
> + * @state: Connector state to set the property on.
> + * @property: Property to set.
> + * @val: New value for the property.
> + *
> + * Sets the atomic property value for a digital connector.
> + */
> +int intel_digital_connector_a

Re: [Intel-gfx] [PATCH v4.1 01/9] drm/atomic: Handle aspect ratio and scaling mode in core, v2.

[Daniel Vetter]

On Thu, Apr 13, 2017 at 11:15:37AM +0200, Maarten Lankhorst wrote:
> This is required to for i915 to convert connector properties to atomic.
> 
> Changes since v1:
> - Add docbook info. (danvet)
> - Change picture_aspect_ratio to enum hdmi_picture_aspect.
> 
> Signed-off-by: Maarten Lankhorst 
> Cc: dri-de...@lists.freedesktop.org
> Acked-by: Dave Airlie 
> ---
>  drivers/gpu/drm/drm_atomic.c |  8 
>  include/drm/drm_connector.h  | 16 
>  2 files changed, 24 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 30229ab719c0..25ea6f797a54 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1123,6 +1123,10 @@ int drm_atomic_connector_set_property(struct 
> drm_connector *connector,
>*/
>   if (state->link_status != DRM_LINK_STATUS_GOOD)
>   state->link_status = val;
> + } else if (property == config->aspect_ratio_property) {
> + state->picture_aspect_ratio = val;
> + } else if (property == config->scaling_mode_property) {
> + state->scaling_mode = val;
>   } else if (connector->funcs->atomic_set_property) {
>   return connector->funcs->atomic_set_property(connector,
>   state, property, val);
> @@ -1199,6 +1203,10 @@ drm_atomic_connector_get_property(struct drm_connector 
> *connector,
>   *val = state->tv.hue;
>   } else if (property == config->link_status_property) {
>   *val = state->link_status;
> + } else if (property == config->aspect_ratio_property) {
> + *val = state->picture_aspect_ratio;
> + } else if (property == config->scaling_mode_property) {
> + *val = state->scaling_mode;
>   } else if (connector->funcs->atomic_get_property) {
>   return connector->funcs->atomic_get_property(connector,
>   state, property, val);
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 4eeda120e46d..5b50bc2db6fb 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -25,6 +25,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include 
> @@ -326,6 +327,21 @@ struct drm_connector_state {
>   struct drm_atomic_state *state;
>  
>   struct drm_tv_connector_state tv;
> +
> + /**
> +  * @picture_aspect_ratio: Connector property to control the
> +  * HDMI infoframe aspect ratio setting.
> +  *
> +  * The DRM_MODE_PICTURE_ASPECT_* values much match the

I think the above will upset sphinx and spew a warning, you need
ASPECT_\* or something like that. Or just spell them out and enumerate
them all. Fixed either way this is

Reviewed-by: Daniel Vetter 

> +  * values for &enum hdmi_picture_aspect
> +  */
> + enum hdmi_picture_aspect picture_aspect_ratio;
> +
> + /**
> +  * @scaling_mode: Connector property to control the
> +  * upscaling, mostly used for built-in panels.
> +  */
> + unsigned int scaling_mode;
>  };
>  
>  /**
> -- 
> 2.7.4
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
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 i-g-t 03/13] lib/igt_aux: Include unistd.h for gettid() on Android

[Jani Nikula]

On Wed, 19 Apr 2017, Arkadiusz Hiler  wrote:
> On Wed, Apr 19, 2017 at 03:22:19PM +0300, Jani Nikula wrote:
>> On Wed, 19 Apr 2017, Arkadiusz Hiler  wrote:
>> > We define gettid() using syscall() because glibc does not provide a
>> > wrapper.
>> >
>> > Android's bionic got the syscall covered though.
>> >
>> > Signed-off-by: Arkadiusz Hiler 
>> > ---
>> >  lib/igt_aux.h | 5 +
>> >  1 file changed, 5 insertions(+)
>> >
>> > diff --git a/lib/igt_aux.h b/lib/igt_aux.h
>> > index e62858e..54b9716 100644
>> > --- a/lib/igt_aux.h
>> > +++ b/lib/igt_aux.h
>> > @@ -43,7 +43,12 @@ extern int num_trash_bos;
>> >  #define NSEC_PER_SEC (1000*USEC_PER_SEC)
>> >  
>> >  /* signal interrupt helpers */
>> > +#ifdef ANDROID
>> 
>> Seems like this should be something like HAVE_GETTID, defined by
>> configure or by android makefiles?
>
> Yeah, but that's not that easy (yet) and that's not the only area which
> would use it - notice the thing with cairo from the cover letter.
>
> config.h is generated in a ugly way for Android - lib/Android.mk does
> that. Also if you ./configure it stops compiling for Android causing
> confusing error.
>
> Whole area could use some heavy reworking.
>
> One approach would be to mimic what other projects do:
>
>  * have config_android.h with set of sane #defines (as environment is
>more static and there is no ac/am)
>
>  * don't define HAVE_CONFIG_H and just `-include config_android.h` on...
>Android
>
>  * add gettid() discovery via ac for Linux (I don't think that any
>libc other than bionic wraps that call though)
>
>
> But that would made a whole series.
> I would like to go with #ifdef ANDROID for now.

Fair enough.

It's just that I cringe seeing #ifdef  instead of #ifdef
, when  and  are not interchangeable or
1:1. For example, glibc might include gettid later.

BR,
Jani.

-- 
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 2/2] drm/i915: Reset hangcheck timeouts upon idling

[Mika Kuoppala]

Chris Wilson  writes:

> If we have a long period of idleness, we turn off the hangcheck timer
> and stop polling the hardware. Before we restart the hangcheck, we
> should clear the previous timestamps to prevent us thinking that the
> engine was stalled for a long time, if the seqno were manipulated
> carefully (such as the repeating patterns in gem_exec_whisper).
>
> It should have no impact upon normal use.
>
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/intel_hangcheck.c | 14 ++
>  1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_hangcheck.c 
> b/drivers/gpu/drm/i915/intel_hangcheck.c
> index b0ca0c4c70d9..a74decca5109 100644
> --- a/drivers/gpu/drm/i915/intel_hangcheck.c
> +++ b/drivers/gpu/drm/i915/intel_hangcheck.c
> @@ -409,13 +409,13 @@ static void i915_hangcheck_elapsed(struct work_struct 
> *work)
>   int busy_count = 0;
>  
>   if (!i915.enable_hangcheck)
> - return;
> + goto disarm_hangcheck;
>  
>   if (!READ_ONCE(dev_priv->gt.awake))
> - return;
> + goto disarm_hangcheck;
>  
>   if (i915_terminally_wedged(&dev_priv->gpu_error))
> - return;
> + goto disarm_hangcheck;
>  
>   /* As enabling the GPU requires fairly extensive mmio access,
>* periodically arm the mmio checker to see if we are triggering
> @@ -446,8 +446,14 @@ static void i915_hangcheck_elapsed(struct work_struct 
> *work)
>   hangcheck_declare_hang(dev_priv, hung, stuck);
>  
>   /* Reset timer in case GPU hangs without another request being added */
> - if (busy_count)
> + if (busy_count) {
>   i915_queue_hangcheck(dev_priv);

Now if we don't have a waiter, we always init hangcheck. And thus
we never detect a hang if so. As demonstrated by the
gem_busy@basic-default-hang.

I suggest we decouple the waiters completely from hangcheck:

-   const bool busy = intel_engine_has_waiter(engine);
+   const bool busy = engine->timeline->inflight_seqnos;

-Mika

> + return;
> + }
> +
> +disarm_hangcheck:
> + for_each_engine(engine, dev_priv, id)
> + intel_engine_init_hangcheck(engine);
>  }
>  
>  void intel_engine_init_hangcheck(struct intel_engine_cs *engine)
> -- 
> 2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t 03/13] lib/igt_aux: Include unistd.h for gettid() on Android

[Arkadiusz Hiler]

On Wed, Apr 19, 2017 at 03:22:19PM +0300, Jani Nikula wrote:
> On Wed, 19 Apr 2017, Arkadiusz Hiler  wrote:
> > We define gettid() using syscall() because glibc does not provide a
> > wrapper.
> >
> > Android's bionic got the syscall covered though.
> >
> > Signed-off-by: Arkadiusz Hiler 
> > ---
> >  lib/igt_aux.h | 5 +
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/lib/igt_aux.h b/lib/igt_aux.h
> > index e62858e..54b9716 100644
> > --- a/lib/igt_aux.h
> > +++ b/lib/igt_aux.h
> > @@ -43,7 +43,12 @@ extern int num_trash_bos;
> >  #define NSEC_PER_SEC (1000*USEC_PER_SEC)
> >  
> >  /* signal interrupt helpers */
> > +#ifdef ANDROID
> 
> Seems like this should be something like HAVE_GETTID, defined by
> configure or by android makefiles?

Yeah, but that's not that easy (yet) and that's not the only area which
would use it - notice the thing with cairo from the cover letter.

config.h is generated in a ugly way for Android - lib/Android.mk does
that. Also if you ./configure it stops compiling for Android causing
confusing error.

Whole area could use some heavy reworking.

One approach would be to mimic what other projects do:

 * have config_android.h with set of sane #defines (as environment is
   more static and there is no ac/am)

 * don't define HAVE_CONFIG_H and just `-include config_android.h` on...
   Android

 * add gettid() discovery via ac for Linux (I don't think that any
   libc other than bionic wraps that call though)


But that would made a whole series.
I would like to go with #ifdef ANDROID for now.

-- 
Cheers,
Arek

> > +#include  /* on Android bionic has this implemented */
> > +#else
> >  #define gettid() syscall(__NR_gettid)
> > +#endif
> > +
> >  #define sigev_notify_thread_id _sigev_un._tid
> >  
> >  /* auxialiary igt helpers from igt_aux.c */
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v6 05/20] drm/i915/tdr: Add support for per engine reset recovery

[Chris Wilson]

On Wed, Apr 19, 2017 at 11:49:26AM +0100, Chris Wilson wrote:
> On Tue, Apr 18, 2017 at 01:23:20PM -0700, Michel Thierry wrote:
> > +   ret = i915_gem_reset_prepare_engine(engine);
> > +   if (ret) {
> > +   DRM_ERROR("Previous reset failed - promote to full reset\n");
> > +   goto error;
> > +   }
> > +
> > +   /*
> > +* the request that caused the hang is stuck on elsp, identify the
> > +* active request and drop it, adjust head to skip the offending
> > +* request to resume executing remaining requests in the queue.
> > +*/
> 
> Hmm. Interesting. This relies on i915_gem_retire_requests() (i.e.
> struct_mutex) to skip replaying innocent requests, but here we should be
> asserting that we do have the hung request.
> 
> i.e.
> request = i915_gem_find_active_request(engine);
> if (!request)
>   goto skip.

Forgot to mention this should include a "pardoned" check, i.e. that the
active request still matches the watchdog seqno.
-Chris

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

[Intel-gfx] [PATCH i-g-t v2] lib/igt_aux: Make procps optional

[Arkadiusz Hiler]

Android does not have procps and it's not easy to compile it as a
dependency.

We can provide alternative, "naive" implementation that just shells out
to external commands (i.e. pkill and lsof) in case we do not have the
library.

v2: do not ifdef insides of functions (J. Nikula)

Cc: Jani Nikula 
Signed-off-by: Arkadiusz Hiler 
---
 configure.ac  |  6 +-
 lib/igt_aux.c | 32 +---
 2 files changed, 34 insertions(+), 4 deletions(-)

diff --git a/configure.ac b/configure.ac
index 12b0ab0..a5a92d5 100644
--- a/configure.ac
+++ b/configure.ac
@@ -123,7 +123,11 @@ AC_SUBST(ASSEMBLER_WARN_CFLAGS)
 PKG_CHECK_MODULES(DRM, [libdrm])
 PKG_CHECK_MODULES(PCIACCESS, [pciaccess >= 0.10])
 PKG_CHECK_MODULES(KMOD, [libkmod])
-PKG_CHECK_MODULES(PROCPS, [libprocps])
+PKG_CHECK_MODULES(PROCPS, [libprocps], [procps=yes], [procps=no])
+AM_CONDITIONAL(HAVE_PROCPS, [test "x$procps" = xyes])
+if test x"$procps" = xyes; then
+   AC_DEFINE(HAVE_PROCPS,1,[Enable process managment without shelling out])
+fi
 PKG_CHECK_MODULES(VALGRIND, [valgrind], [have_valgrind=yes], 
[have_valgrind=no])
 
 if test x$have_valgrind = xyes; then
diff --git a/lib/igt_aux.c b/lib/igt_aux.c
index 2ec6b78..3695fa5 100644
--- a/lib/igt_aux.c
+++ b/lib/igt_aux.c
@@ -50,9 +50,7 @@
 #include 
 #include 
 #include 
-
-#include 
-
+#include 
 #include "drmtest.h"
 #include "i915_drm.h"
 #include "intel_chipset.h"
@@ -71,6 +69,10 @@
 #include/* for dirname() */
 #endif
 
+#ifdef HAVE_PROCPS
+#include 
+#endif
+
 /**
  * SECTION:igt_aux
  * @short_description: Auxiliary libraries and support functions
@@ -1281,6 +1283,7 @@ void igt_set_module_param_int(const char *name, int val)
igt_set_module_param(name, str);
 }
 
+#ifdef HAVE_PROCPS
 /**
  * igt_terminate_process:
  * @sig: Signal to send
@@ -1317,7 +1320,18 @@ int igt_terminate_process(int sig, const char *comm)
closeproc(proc);
return err;
 }
+#else /* HAVE_PROCPS */
+#warning "No procps, using naive implementatio of igt_terminate_process"
 
+int igt_terminate_process(int sig, const char *comm)
+{
+   char pkill_cmd[NAME_MAX];
+   snprintf(pkill_cmd, sizeof(pkill_cmd), "pkill -x -%d %s", sig, comm);
+   return system(pkill_cmd);
+}
+#endif /* HAVE_PROCPS */
+
+#ifdef HAVE_PROCPS
 struct pinfo {
pid_t pid;
const char *comm;
@@ -1531,6 +1545,18 @@ igt_lsof(const char *dpath)
 
free(sanitized);
 }
+#else /* HAVE_PROCPS */
+#warning "No procps, using naive implementatio of igt_lsof"
+
+void
+igt_lsof(const char *dpath)
+{
+   char lsof_cmd[NAME_MAX];
+   snprintf(lsof_cmd, sizeof(lsof_cmd), "lsof +d %s", dpath);
+   system(lsof_cmd);
+
+}
+#endif /* HAVE_PROCPS */
 
 static struct igt_siglatency {
timer_t timer;
-- 
2.9.3

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

Re: [Intel-gfx] [PATCH] drm: i915: Avoid format string expansion from engine names

[Jani Nikula]

On Tue, 11 Apr 2017, Kees Cook  wrote:
> While highly unlikely, this makes sure that the string built from
> engine names won't be processed as a format string.
>
> Signed-off-by: Kees Cook 

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

BR,
Jani.

> ---
>  drivers/gpu/drm/i915/intel_hangcheck.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_hangcheck.c 
> b/drivers/gpu/drm/i915/intel_hangcheck.c
> index f05971f5586f..be3550cec8e4 100644
> --- a/drivers/gpu/drm/i915/intel_hangcheck.c
> +++ b/drivers/gpu/drm/i915/intel_hangcheck.c
> @@ -407,7 +407,7 @@ static void hangcheck_declare_hang(struct 
> drm_i915_private *i915,
>"%s, ", engine->name);
>   msg[len-2] = '\0';
>  
> - return i915_handle_error(i915, hung, msg);
> + return i915_handle_error(i915, hung, "%s", msg);
>  }
>  
>  /*
> -- 
> 2.7.4

-- 
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 igt] tests/gem_spin_batch: Add multiengine test

[Mika Kuoppala]

Chris Wilson  writes:

> On Thu, Apr 13, 2017 at 01:02:37PM +0300, Mika Kuoppala wrote:
>> Parallel spin on all engines.
>> 
>> Signed-off-by: Mika Kuoppala 
>> ---
>>  tests/gem_spin_batch.c | 31 +--
>>  1 file changed, 29 insertions(+), 2 deletions(-)
>> 
>> diff --git a/tests/gem_spin_batch.c b/tests/gem_spin_batch.c
>> index baf796a..a22da32 100644
>> --- a/tests/gem_spin_batch.c
>> +++ b/tests/gem_spin_batch.c
>> @@ -32,7 +32,7 @@
>>   "'%s' != '%s' (%lld not within %d%% tolerance of %lld)\n",\
>>   #x, #ref, (long long)x, tolerance, (long long)ref)
>>  
>> -static void basic(int fd, unsigned int engine, unsigned int timeout_sec)
>> +static void spin(int fd, unsigned int engine, unsigned int timeout_sec)
>>  {
>>  const uint64_t timeout_100ms = 1LL;
>>  unsigned long loops = 0;
>> @@ -63,6 +63,30 @@ static void basic(int fd, unsigned int engine, unsigned 
>> int timeout_sec)
>>  igt_assert_eq(intel_detect_and_clear_missed_interrupts(fd), 0);
>>  }
>>  
>> +static void spin_exit_handler(int sig)
>> +{
>> +igt_fixture {
>
> Should not be required?
>
>> +igt_terminate_spin_batches();
>> +}
>> +}
>> +
>> +static void spin_on_all_engines(int fd, unsigned int timeout_sec)
>> +{
>> +unsigned engine;
>> +
>> +for_each_engine(fd, engine) {
>> +if (engine == 0)
>> +continue;
>> +
>> +igt_fork(child, 1) {
>> +igt_install_exit_handler(spin_exit_handler);
>
> Ok. The existing igt_terminate_spin_batches() is tied into the exit
> handler of the parent process (from quiescent_gpu_at_exit).
>
>> +spin(fd, engine, timeout_sec);
>> +}
>> +}
>> +
>> +igt_waitchildren();
>> +}
>> +
>>  igt_main
>>  {
>>  const struct intel_execution_engine *e;
>> @@ -82,9 +106,12 @@ igt_main
>>  continue;
>>  
>>  igt_subtest_f("basic-%s", e->name)
>> -basic(fd, e->exec_id, 3);
>> +spin(fd, e->exec_id, 3);
>>  }
>>  
>> +igt_subtest("multiengine")
>
> I would call this spin-each, to try and differentiate this
> spin on each engine independently from a second variant that shared a
> single batch between all engines (spin-all).
>
> That make take some tweaks to igt_spin_batch (hmm, actually should not be
> that difficult...) and might be worth doing just in case there's a
> diffference in TLB behaviour or whatnot.
>

Renamed the test and removed the fixture.

> Reviewed-by: Chris Wilson 

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

Re: [Intel-gfx] [PATCH i-g-t 04/13] lib/igt_aux: Make procps optional

[Jani Nikula]

On Wed, 19 Apr 2017, Arkadiusz Hiler  wrote:
> Android does not have procps and it's not easy to compile it as a
> dependency.
>
> We can provide alternative, "naive" implementation that just shells out
> to external commands (i.e. pkill and lsof) in case we do not have the
> library.
>
> Signed-off-by: Arkadiusz Hiler 
> ---
>  configure.ac  |  6 +-
>  lib/igt_aux.c | 24 +---
>  2 files changed, 26 insertions(+), 4 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 12b0ab0..a5a92d5 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -123,7 +123,11 @@ AC_SUBST(ASSEMBLER_WARN_CFLAGS)
>  PKG_CHECK_MODULES(DRM, [libdrm])
>  PKG_CHECK_MODULES(PCIACCESS, [pciaccess >= 0.10])
>  PKG_CHECK_MODULES(KMOD, [libkmod])
> -PKG_CHECK_MODULES(PROCPS, [libprocps])
> +PKG_CHECK_MODULES(PROCPS, [libprocps], [procps=yes], [procps=no])
> +AM_CONDITIONAL(HAVE_PROCPS, [test "x$procps" = xyes])
> +if test x"$procps" = xyes; then
> + AC_DEFINE(HAVE_PROCPS,1,[Enable process managment without shelling out])
> +fi
>  PKG_CHECK_MODULES(VALGRIND, [valgrind], [have_valgrind=yes], 
> [have_valgrind=no])
>  
>  if test x$have_valgrind = xyes; then
> diff --git a/lib/igt_aux.c b/lib/igt_aux.c
> index 2ec6b78..4efb45b 100644
> --- a/lib/igt_aux.c
> +++ b/lib/igt_aux.c
> @@ -50,9 +50,7 @@
>  #include 
>  #include 
>  #include 
> -
> -#include 
> -
> +#include 
>  #include "drmtest.h"
>  #include "i915_drm.h"
>  #include "intel_chipset.h"
> @@ -71,6 +69,10 @@
>  #include/* for dirname() */
>  #endif
>  
> +#ifdef HAVE_PROCPS
> +#include 
> +#endif
> +
>  /**
>   * SECTION:igt_aux
>   * @short_description: Auxiliary libraries and support functions
> @@ -1295,6 +1297,7 @@ void igt_set_module_param_int(const char *name, int val)
>   */
>  int igt_terminate_process(int sig, const char *comm)
>  {
> +#ifdef HAVE_PROCPS

Please move ifdefs *outside* the functions, and add another function for
the !HAVE_PROCPS branch.

Same below.

BR,
Jani.

>   PROCTAB *proc;
>   proc_t *proc_info;
>   int err = 0;
> @@ -1316,6 +1319,12 @@ int igt_terminate_process(int sig, const char *comm)
>  
>   closeproc(proc);
>   return err;
> +#else
> +#warning "No procps, using naive implementation of igt_terminate_process"
> + char pkill_cmd[NAME_MAX];
> + snprintf(pkill_cmd, sizeof(pkill_cmd), "pkill -x -%d %s", sig, comm);
> + return system(pkill_cmd);
> +#endif
>  }
>  
>  struct pinfo {
> @@ -1324,6 +1333,7 @@ struct pinfo {
>   const char *fn;
>  };
>  
> +#ifdef HAVE_PROCPS
>  static void
>  __igt_show_stat(struct pinfo *info)
>  {
> @@ -1499,6 +1509,7 @@ __igt_lsof(const char *dir)
>  
>   closeproc(proc);
>  }
> +#endif
>  
>  /**
>   * igt_lsof: Lists information about files opened by processes.
> @@ -1510,6 +1521,7 @@ __igt_lsof(const char *dir)
>  void
>  igt_lsof(const char *dpath)
>  {
> +#ifdef HAVE_PROCPS
>   struct stat st;
>   size_t len = strlen(dpath);
>   char *sanitized;
> @@ -1530,6 +1542,12 @@ igt_lsof(const char *dpath)
>   __igt_lsof(sanitized);
>  
>   free(sanitized);
> +#else
> +#warning "No procps, using naive implementation of igt_lsof"
> + char lsof_cmd[NAME_MAX];
> + snprintf(lsof_cmd, sizeof(lsof_cmd), "lsof +d %s", dpath);
> + system(lsof_cmd);
> +#endif
>  }
>  
>  static struct igt_siglatency {

-- 
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 i-g-t 03/13] lib/igt_aux: Include unistd.h for gettid() on Android

[Jani Nikula]

On Wed, 19 Apr 2017, Arkadiusz Hiler  wrote:
> We define gettid() using syscall() because glibc does not provide a
> wrapper.
>
> Android's bionic got the syscall covered though.
>
> Signed-off-by: Arkadiusz Hiler 
> ---
>  lib/igt_aux.h | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/lib/igt_aux.h b/lib/igt_aux.h
> index e62858e..54b9716 100644
> --- a/lib/igt_aux.h
> +++ b/lib/igt_aux.h
> @@ -43,7 +43,12 @@ extern int num_trash_bos;
>  #define NSEC_PER_SEC (1000*USEC_PER_SEC)
>  
>  /* signal interrupt helpers */
> +#ifdef ANDROID

Seems like this should be something like HAVE_GETTID, defined by
configure or by android makefiles?

BR,
Jani.

> +#include  /* on Android bionic has this implemented */
> +#else
>  #define gettid() syscall(__NR_gettid)
> +#endif
> +
>  #define sigev_notify_thread_id _sigev_un._tid
>  
>  /* auxialiary igt helpers from igt_aux.c */

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

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

[Hans de Goede]

Several Bay / Cherry Trail devices (all of which ship with Windows 10) hide
the LPSS PWM controller in ACPI, typically the _STA method looks like this:

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

Return (0x0F)
}

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

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

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

Signed-off-by: Hans de Goede 
---
Changes in v2:
-Use pr_debug instead of ACPI_DEBUG_PRINT
Changes in v3:
-Un-inline acpi_set_device_status and do the always_present_device_ids
 table check inside the un-inlined version of it
Changes in v4:
-Use dev_info instead of pr_debug
-Not only check for ACPI HID but also for CPU (SoC) model so as to not
 for devices present on other models then for which the quirk is intended and
 to avoid enabling unrelated ACPI devices which happen to use the same HID
Changes in v5:
-Only do the dev_info once per device (acpi_set_device_status gets called
 multiple times per device during boot)
Changes in v6:
-Allow specifying more then one CPU-model for a single HID
-Not only match the HID but also the UID, like on Cherry Trail, on some Bay
 Trail Windows 10 tablets we need to enable the PWM controller to get working
 backlight even though _STA returns 0. The Bay Trail SoC has 2 PWM controllers
 and we only need the first one. UID matching will allows adding an entry for
 Bay Trail which only enables the first PWM controller
Changes in v7:
-Put the actual x86 specific matching code and table with always present
 device HID + UID + CPU model entries in a new x86/x86_utils.c file which
 provides an acpi_device_always_present() helper function on x86, on
 non x86 a stub which always returns false is provided
-Squash in the addition of the Bay Trail PWM entry in the table as it
 is there for the same reasons as the Cherry Trail entry is there
---
 drivers/acpi/Makefile|  1 +
 drivers/acpi/bus.c   | 10 ++
 drivers/acpi/x86/x86_utils.c | 85 
 include/acpi/acpi_bus.h  | 15 +---
 4 files changed, 106 insertions(+), 5 deletions(-)
 create mode 100644 drivers/acpi/x86/x86_utils.c

diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index d78065c..f3940ac 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -50,6 +50,7 @@ acpi-$(CONFIG_ACPI_REDUCED_HARDWARE_ONLY) += evged.o
 acpi-y += sysfs.o
 acpi-y += property.o
 acpi-$(CONFIG_X86) += acpi_cmos_rtc.o
+acpi-$(CONFIG_X86) += x86/x86_utils.o
 acpi-$(CONFIG_DEBUG_FS)+= debugfs.o
 acpi-$(CONFIG_ACPI_NUMA)   += numa.o
 acpi-$(CONFIG_ACPI_PROCFS_POWER) += cm_sbs.o
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 34fbe02..4d952cc 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -132,6 +132,16 @@ int acpi_bus_get_status(struct acpi_device *device)
 }
 EXPORT_SYMBOL(acpi_bus_get_status);
 
+void acpi_set_device_status(struct acpi_device *adev, u32 sta)
+{
+   u32 *status = (u32 *)&adev->status;
+
+   if (acpi_device_always_present(adev))
+   *status = ACPI_STA_DEFAULT;
+   else
+   *status = sta;
+}
+
 void acpi_bus_private_data_handler(acpi_handle handle,
   void *context)
 {
diff --git a/drivers/acpi/x86/x86_utils.c b/drivers/acpi/x86/x86_utils.c
new file mode 100644
index 000..74f1237
--- /dev/null
+++ b/drivers/acpi/x86/x86_utils.c
@@ -0,0 +1,85 @@
+/*
+ *  X86 ACPI Utility Functions
+ *
+ * Copyright (C) 2017 Hans de Goede 
+ *
+ * Based on various non upstream patches to support the CHT Whiskey Cove PMIC:
+ * Copyright (C) 2013-2015 Intel Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include "../internal.h"
+
+/*
+ * Some ACPI devices are hidden (status == 0x0) in recent BIOS-es because
+ * some recent Windows drivers bind to one device but poke at multiple
+ * devices at the same time, so the others get hidden.
+ * We work around this by always reporting ACPI_STA_DEFAULT for these
+ * devices. Note this MUST only be done for devices where this is safe.
+ *
+ * This

[Intel-gfx] [PATCH v7 2/2] ACPI / bus: Add INT0002 to list of always-present devices

[Hans de Goede]

The INT0002 device is necessary to clear wakeup interrupt sources
on Cherry Trail devices, without it we get nobody cared IRQ msgs
and some systems don't properly resume at all without it.

Signed-off-by: Hans de Goede 
---
Changes in v6:
-This is a new patch in v6 of this patch-set
Changes in v7:
-Adjust for the always present devices table being moved to
 drivers/acpi/x86/x86_utils.c
---
 drivers/acpi/x86/x86_utils.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/acpi/x86/x86_utils.c b/drivers/acpi/x86/x86_utils.c
index 74f1237..98d875a 100644
--- a/drivers/acpi/x86/x86_utils.c
+++ b/drivers/acpi/x86/x86_utils.c
@@ -49,6 +49,11 @@ static const struct always_present_id always_present_ids[] = 
{
 */
ENTRY("80860F09", "1", ICPU(INTEL_FAM6_ATOM_SILVERMONT1)),
ENTRY("80862288", "1", ICPU(INTEL_FAM6_ATOM_AIRMONT)),
+   /*
+* The INT0002 device is necessary to clear wakeup interrupt sources
+* on Cherry Trail devices, without it we get nobody cared IRQ msgs.
+*/
+   ENTRY("INT0002", "1", ICPU(INTEL_FAM6_ATOM_AIRMONT)),
 };
 
 bool acpi_device_always_present(struct acpi_device *adev)
-- 
2.9.3

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

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Fix GCC 4.4 build issue with __intel_wait_for_register_fw (rev2)

[Tvrtko Ursulin]

On 18/04/2017 12:17, Patchwork wrote:

== Series Details ==

Series: drm/i915: Fix GCC 4.4 build issue with __intel_wait_for_register_fw 
(rev2)
URL   : https://patchwork.freedesktop.org/series/23020/
State : failure

== Summary ==

Series 23020v2 drm/i915: Fix GCC 4.4 build issue with 
__intel_wait_for_register_fw
https://patchwork.freedesktop.org/api/1.0/series/23020/revisions/2/mbox/

Test gem_exec_suspend:
Subgroup basic-s4-devices:
dmesg-warn -> PASS   (fi-kbl-7560u) fdo#100125
Test pm_rpm:
Subgroup basic-pci-d3-state:
pass   -> INCOMPLETE (fi-bsw-n3050)


Unrelated BSW hang:
https://bugs.freedesktop.org/show_bug.cgi?id=100718


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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:430s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:423s
fi-bsw-n3050 total:241  pass:206  dwarn:0   dfail:0   fail:0   skip:34
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:511s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:484s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:480s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:409s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:411s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:423s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:486s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:468s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:459s
fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:563s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:451s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:572s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:463s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:499s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:432s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:531s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:398s

4d374295ace9e57d83483341e2ad07cad5baf912 drm-tip: 2017y-04m-18d-10h-08m-05s UTC 
integration manifest
cf1a97e drm/i915: Fix GCC 4.4 build issue with __intel_wait_for_register_fw


Pushed, thanks for the review!

Regards,

Tvrtko

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

Re: [Intel-gfx] [PATCH 27/27] drm/i915/scheduler: Support user-defined priorities

[Tvrtko Ursulin]

On 19/04/2017 11:09, Chris Wilson wrote:

On Wed, Apr 19, 2017 at 10:41:43AM +0100, Chris Wilson wrote:

diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index f43a22ae955b..200f2cf393b2 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -395,6 +395,8 @@ typedef struct drm_i915_irq_wait {

 /* Query whether DRM_I915_GEM_EXECBUFFER2 supports user defined execution
  * priorities and the driver will attempt to execute batches in priority order.
+ * The initial priority for each batch is supplied by the context and is
+ * controlled via I915_CONTEXT_PARAM_PRIORITY.
  */
 #define I915_PARAM_HAS_SCHEDULER41
 #define I915_PARAM_HUC_STATUS   42
@@ -1318,6 +1320,7 @@ struct drm_i915_gem_context_param {
 #define I915_CONTEXT_PARAM_GTT_SIZE0x3
 #define I915_CONTEXT_PARAM_NO_ERROR_CAPTURE0x4
 #define I915_CONTEXT_PARAM_BANNABLE0x5
+#define I915_CONTEXT_PARAM_PRIORITY0x6


Grr. Forgot to add min/max defines.

#define I915_CONTEXT_MAX_USER_PRIORITY  1023 /* inclusive */
#define I915_CONTEXT_DEFAULT_PRIORITY   0
#define I915_CONTEXT_MIN_USER_PRIORITY  -1023 /* inclusive */


Yes, and use these in context get param, including the default instead 
of the zero I think.



Or should it be I915_CONTEXT_PRIORITY_MAX_USER etc?


Priority last somehow looks better to me since like that it is clearly a 
separate category from param names. But I don't mind either way.


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 09/13] Android.mk: Fix libkmod use

[Arkadiusz Hiler]

On Android libkmod.h is nested under libkmod directory, so we should
include appropriately.

Also we need to link with it.

Signed-off-by: Arkadiusz Hiler 
---
 benchmarks/Android.mk | 2 ++
 lib/Android.mk| 1 +
 lib/igt_kmod.h| 4 
 tests/Android.mk  | 4 ++--
 tools/Android.mk  | 2 ++
 5 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/benchmarks/Android.mk b/benchmarks/Android.mk
index a790ec7..fa9eec6 100644
--- a/benchmarks/Android.mk
+++ b/benchmarks/Android.mk
@@ -18,6 +18,7 @@ define add_benchmark
 LOCAL_CFLAGS += -Wno-error=return-type
 # Excessive complaining for established cases. Rely on the Linux version 
warnings.
 LOCAL_CFLAGS += -Wno-sign-compare
+LOCAL_LDFLAGS += -lkmod
 
 LOCAL_MODULE := $1_benchmark
 LOCAL_MODULE_TAGS := optional
@@ -26,6 +27,7 @@ define add_benchmark
 LOCAL_STATIC_LIBRARIES := libintel_gpu_tools
 
 LOCAL_SHARED_LIBRARIES := libpciaccess  \
+  libkmod   \
   libdrm\
   libdrm_intel
 
diff --git a/lib/Android.mk b/lib/Android.mk
index eb72f84..0596e4a 100644
--- a/lib/Android.mk
+++ b/lib/Android.mk
@@ -29,6 +29,7 @@ LOCAL_CFLAGS += -std=gnu99 -UNDEBUG
 LOCAL_MODULE:= libintel_gpu_tools
 
 LOCAL_SHARED_LIBRARIES := libpciaccess  \
+ libkmod   \
  libdrm\
  libdrm_intel
 
diff --git a/lib/igt_kmod.h b/lib/igt_kmod.h
index fd307a4..6a7584f 100644
--- a/lib/igt_kmod.h
+++ b/lib/igt_kmod.h
@@ -24,7 +24,11 @@
 #ifndef IGT_KMOD_H
 #define IGT_KMOD_H
 
+#ifdef ANDROID
+#include 
+#else
 #include 
+#endif
 
 #include "igt_aux.h"
 
diff --git a/tests/Android.mk b/tests/Android.mk
index c67ddbd..b664dff 100644
--- a/tests/Android.mk
+++ b/tests/Android.mk
@@ -19,7 +19,7 @@ define add_test
 
 LOCAL_MODULE_TAGS := optional
 # ask linker to define a specific symbol; we use this to identify IGT tests
-LOCAL_LDFLAGS := -Wl,--defsym=$2=0
+LOCAL_LDFLAGS := -Wl,--defsym=$2=0 -lkmod
 LOCAL_MODULE_PATH := $(TARGET_OUT_VENDOR)/intel/validation/core/igt
 
 include $(BUILD_EXECUTABLE)
@@ -45,7 +45,7 @@ IGT_LOCAL_C_INCLUDES += 
${ANDROID_BUILD_TOP}/external/PRIVATE/drm/include/drm
 
 # set local libraries
 IGT_LOCAL_STATIC_LIBRARIES := libintel_gpu_tools
-IGT_LOCAL_SHARED_LIBRARIES := libpciaccess libdrm libdrm_intel
+IGT_LOCAL_SHARED_LIBRARIES := libpciaccess libkmod libdrm libdrm_intel
 
 # handle cairo requirements if it is enabled
 ifeq ("${ANDROID_HAS_CAIRO}", "1")
diff --git a/tools/Android.mk b/tools/Android.mk
index 0602e8c..a8e649b 100644
--- a/tools/Android.mk
+++ b/tools/Android.mk
@@ -23,6 +23,7 @@ define add_tool
 LOCAL_CFLAGS += -Wno-error=return-type
 # Excessive complaining for established cases. Rely on the Linux version 
warnings.
 LOCAL_CFLAGS += -Wno-sign-compare
+LOCAL_LDFLAGS += -lkmod
 ifeq ($($(1)_LDFLAGS),)
 else
 LOCAL_LDFLAGS += $($(1)_LDFLAGS)
@@ -38,6 +39,7 @@ define add_tool
 LOCAL_STATIC_LIBRARIES := libintel_gpu_tools
 
 LOCAL_SHARED_LIBRARIES := libpciaccess  \
+  libkmod   \
   libdrm\
   libdrm_intel
 
-- 
2.9.3

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

[Intel-gfx] [PATCH i-g-t 05/13] chamelium: Fix build issues on Android

[Arkadiusz Hiler]

Makefile.sources are included 1:1 in Android.mk files, and are not
parsed by automake. And yet those had some automake conditional logic.
Moving it to .am file is enough for now.

Also igt_chamelium.h included config.h without proper "HAVE_CONFIG_H"
guard, and the file itself was included unconditionally.

Signed-off-by: Arkadiusz Hiler 
---
 lib/Makefile.am| 7 +++
 lib/Makefile.sources   | 7 ---
 lib/igt.h  | 2 ++
 lib/igt_chamelium.h| 3 +++
 tests/Makefile.am  | 6 ++
 tests/Makefile.sources | 6 --
 6 files changed, 18 insertions(+), 13 deletions(-)

diff --git a/lib/Makefile.am b/lib/Makefile.am
index c0ddf29..91e72c4 100644
--- a/lib/Makefile.am
+++ b/lib/Makefile.am
@@ -22,6 +22,13 @@ if !HAVE_LIBDRM_INTEL
 stubs/drm/intel_bufmgr.h
 endif
 
+if HAVE_CHAMELIUM
+lib_source_list += \
+   igt_chamelium.h \
+   igt_chamelium.c \
+   $(NULL)
+endif
+
 AM_CPPFLAGS = -I$(top_srcdir)
 AM_CFLAGS = \
$(CWARNFLAGS) \
diff --git a/lib/Makefile.sources b/lib/Makefile.sources
index 6348487..53fdb54 100644
--- a/lib/Makefile.sources
+++ b/lib/Makefile.sources
@@ -85,13 +85,6 @@ lib_source_list =\
igt_kmod.h  \
$(NULL)
 
-if HAVE_CHAMELIUM
-lib_source_list += \
-   igt_chamelium.h \
-   igt_chamelium.c \
-   $(NULL)
-endif
-
 .PHONY: version.h.tmp
 
 # leaving a space here to work around automake's conditionals
diff --git a/lib/igt.h b/lib/igt.h
index a97923e..a069deb 100644
--- a/lib/igt.h
+++ b/lib/igt.h
@@ -38,7 +38,9 @@
 #include "igt_kms.h"
 #include "igt_pm.h"
 #include "igt_stats.h"
+#ifdef HAVE_CHAMELIUM
 #include "igt_chamelium.h"
+#endif
 #include "instdone.h"
 #include "intel_batchbuffer.h"
 #include "intel_chipset.h"
diff --git a/lib/igt_chamelium.h b/lib/igt_chamelium.h
index f421d83..15f6024 100644
--- a/lib/igt_chamelium.h
+++ b/lib/igt_chamelium.h
@@ -26,7 +26,10 @@
 #ifndef IGT_CHAMELIUM_H
 #define IGT_CHAMELIUM_H
 
+#ifdef HAVE_CONFIG_H
 #include "config.h"
+#endif
+
 #include "igt.h"
 #include 
 
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 8930c24..f2358d5 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -8,6 +8,12 @@ if HAVE_LIBDRM_VC4
 TESTS_progs_M += $(VC4_TESTS_M)
 endif
 
+if HAVE_CHAMELIUM
+TESTS_progs_M += \
+   chamelium \
+   $(NULL)
+endif
+
 if BUILD_TESTS
 test-list.txt: Makefile.sources
@echo TESTLIST > $@
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 7fa9b8f..3f10cd2 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -146,12 +146,6 @@ TESTS_progs_M = \
meta_test \
$(NULL)
 
-if HAVE_CHAMELIUM
-TESTS_progs_M += \
-   chamelium \
-   $(NULL)
-endif
-
 TESTS_progs_XM = \
 gem_concurrent_all \
 $(NULL)
-- 
2.9.3

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

[Intel-gfx] [PATCH i-g-t 04/13] lib/igt_aux: Make procps optional

[Arkadiusz Hiler]

Android does not have procps and it's not easy to compile it as a
dependency.

We can provide alternative, "naive" implementation that just shells out
to external commands (i.e. pkill and lsof) in case we do not have the
library.

Signed-off-by: Arkadiusz Hiler 
---
 configure.ac  |  6 +-
 lib/igt_aux.c | 24 +---
 2 files changed, 26 insertions(+), 4 deletions(-)

diff --git a/configure.ac b/configure.ac
index 12b0ab0..a5a92d5 100644
--- a/configure.ac
+++ b/configure.ac
@@ -123,7 +123,11 @@ AC_SUBST(ASSEMBLER_WARN_CFLAGS)
 PKG_CHECK_MODULES(DRM, [libdrm])
 PKG_CHECK_MODULES(PCIACCESS, [pciaccess >= 0.10])
 PKG_CHECK_MODULES(KMOD, [libkmod])
-PKG_CHECK_MODULES(PROCPS, [libprocps])
+PKG_CHECK_MODULES(PROCPS, [libprocps], [procps=yes], [procps=no])
+AM_CONDITIONAL(HAVE_PROCPS, [test "x$procps" = xyes])
+if test x"$procps" = xyes; then
+   AC_DEFINE(HAVE_PROCPS,1,[Enable process managment without shelling out])
+fi
 PKG_CHECK_MODULES(VALGRIND, [valgrind], [have_valgrind=yes], 
[have_valgrind=no])
 
 if test x$have_valgrind = xyes; then
diff --git a/lib/igt_aux.c b/lib/igt_aux.c
index 2ec6b78..4efb45b 100644
--- a/lib/igt_aux.c
+++ b/lib/igt_aux.c
@@ -50,9 +50,7 @@
 #include 
 #include 
 #include 
-
-#include 
-
+#include 
 #include "drmtest.h"
 #include "i915_drm.h"
 #include "intel_chipset.h"
@@ -71,6 +69,10 @@
 #include/* for dirname() */
 #endif
 
+#ifdef HAVE_PROCPS
+#include 
+#endif
+
 /**
  * SECTION:igt_aux
  * @short_description: Auxiliary libraries and support functions
@@ -1295,6 +1297,7 @@ void igt_set_module_param_int(const char *name, int val)
  */
 int igt_terminate_process(int sig, const char *comm)
 {
+#ifdef HAVE_PROCPS
PROCTAB *proc;
proc_t *proc_info;
int err = 0;
@@ -1316,6 +1319,12 @@ int igt_terminate_process(int sig, const char *comm)
 
closeproc(proc);
return err;
+#else
+#warning "No procps, using naive implementation of igt_terminate_process"
+   char pkill_cmd[NAME_MAX];
+   snprintf(pkill_cmd, sizeof(pkill_cmd), "pkill -x -%d %s", sig, comm);
+   return system(pkill_cmd);
+#endif
 }
 
 struct pinfo {
@@ -1324,6 +1333,7 @@ struct pinfo {
const char *fn;
 };
 
+#ifdef HAVE_PROCPS
 static void
 __igt_show_stat(struct pinfo *info)
 {
@@ -1499,6 +1509,7 @@ __igt_lsof(const char *dir)
 
closeproc(proc);
 }
+#endif
 
 /**
  * igt_lsof: Lists information about files opened by processes.
@@ -1510,6 +1521,7 @@ __igt_lsof(const char *dir)
 void
 igt_lsof(const char *dpath)
 {
+#ifdef HAVE_PROCPS
struct stat st;
size_t len = strlen(dpath);
char *sanitized;
@@ -1530,6 +1542,12 @@ igt_lsof(const char *dpath)
__igt_lsof(sanitized);
 
free(sanitized);
+#else
+#warning "No procps, using naive implementation of igt_lsof"
+   char lsof_cmd[NAME_MAX];
+   snprintf(lsof_cmd, sizeof(lsof_cmd), "lsof +d %s", dpath);
+   system(lsof_cmd);
+#endif
 }
 
 static struct igt_siglatency {
-- 
2.9.3

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

[Intel-gfx] [PATCH i-g-t 07/13] tests/Android.mk: Add perf to skip list

[Arkadiusz Hiler]

It does not build on Android with top libdrm.

Temporary hax.

Signed-off-by: Arkadiusz Hiler 
---
 tests/Android.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tests/Android.mk b/tests/Android.mk
index 3186a2a..c67ddbd 100644
--- a/tests/Android.mk
+++ b/tests/Android.mk
@@ -59,6 +59,7 @@ else
 pm_lpsp \
drm_read \
gem_exec_blt \
+   perf \
prime_mmap_kms
 
 # All kms tests depend on cairo
-- 
2.9.3

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

[Intel-gfx] [PATCH i-g-t 11/13] Android.mk: Use drm stubs

[Arkadiusz Hiler]

Use drm stubs that sit under lib/stubs.

Also drop strange, nonexistent additions to LOCAL_C_INCLUDES.

Signed-off-by: Arkadiusz Hiler 
---
 benchmarks/Android.mk | 3 ++-
 demos/Android.mk  | 3 ++-
 lib/Android.mk| 4 ++--
 lib/tests/Android.mk  | 4 ++--
 tests/Android.mk  | 4 ++--
 tools/Android.mk  | 2 +-
 6 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/benchmarks/Android.mk b/benchmarks/Android.mk
index fa9eec6..a4f1858 100644
--- a/benchmarks/Android.mk
+++ b/benchmarks/Android.mk
@@ -10,7 +10,8 @@ define add_benchmark
 
 LOCAL_SRC_FILES := $1.c
 
-LOCAL_C_INCLUDES = ${IGT_LOCAL_C_INCLUDES}
+LOCAL_C_INCLUDES = ${IGT_LOCAL_C_INCLUDES} \
+   $(LOCAL_PATH)/../lib/stubs/drm/
 LOCAL_CFLAGS += -DHAVE_STRUCT_SYSINFO_TOTALRAM
 LOCAL_CFLAGS += -DANDROID -UNDEBUG -include "check-ndebug.h"
 LOCAL_CFLAGS += -std=gnu99
diff --git a/demos/Android.mk b/demos/Android.mk
index 90d8b37..1f50fdc 100644
--- a/demos/Android.mk
+++ b/demos/Android.mk
@@ -16,7 +16,8 @@ LOCAL_CFLAGS += -std=gnu99
 # Excessive complaining for established cases. Rely on the Linux version 
warnings.
 LOCAL_CFLAGS += -Wno-sign-compare
 
-LOCAL_C_INCLUDES = $(LOCAL_PATH)/../lib
+LOCAL_C_INCLUDES = $(LOCAL_PATH)/../lib \
+   $(LOCAL_PATH)/../lib/stubs/drm/
 
 LOCAL_MODULE := intel_sprite_on
 
diff --git a/lib/Android.mk b/lib/Android.mk
index 003ade5..31f88be 100644
--- a/lib/Android.mk
+++ b/lib/Android.mk
@@ -17,8 +17,8 @@ LOCAL_GENERATED_SOURCES :=   \
$(IGT_LIB_PATH)/version.h  \
$(GPU_TOOLS_PATH)/config.h
 
-LOCAL_C_INCLUDES +=  \
-   $(LOCAL_PATH)/..
+LOCAL_C_INCLUDES += $(LOCAL_PATH)/.. \
+$(LOCAL_PATH)/stubs/drm/
 
 LOCAL_EXPORT_C_INCLUDE_DIRS := $(LOCAL_PATH)
 
diff --git a/lib/tests/Android.mk b/lib/tests/Android.mk
index 026f17f..bbbd4d8 100644
--- a/lib/tests/Android.mk
+++ b/lib/tests/Android.mk
@@ -30,8 +30,8 @@ IGT_LOCAL_CFLAGS += -std=gnu99
 IGT_LOCAL_CFLAGS += -Wno-error=return-type
 
 # set local includes
-IGT_LOCAL_C_INCLUDES = $(LOCAL_PATH)/../lib
-IGT_LOCAL_C_INCLUDES += ${ANDROID_BUILD_TOP}/external/PRIVATE/drm/include/drm
+IGT_LOCAL_C_INCLUDES = $(LOCAL_PATH)/../lib \
+   $(LOCAL_PATH)/../lib/stubs/drm/
 
 # set local libraries
 IGT_LOCAL_STATIC_LIBRARIES := libintel_gpu_tools
diff --git a/tests/Android.mk b/tests/Android.mk
index b664dff..c6e966f 100644
--- a/tests/Android.mk
+++ b/tests/Android.mk
@@ -40,8 +40,8 @@ IGT_LOCAL_CFLAGS += -Wno-error=return-type
 IGT_LOCAL_CFLAGS += -Wno-sign-compare
 
 # set local includes
-IGT_LOCAL_C_INCLUDES = $(LOCAL_PATH)/../lib
-IGT_LOCAL_C_INCLUDES += ${ANDROID_BUILD_TOP}/external/PRIVATE/drm/include/drm
+IGT_LOCAL_C_INCLUDES = $(LOCAL_PATH)/../lib \
+   $(LOCAL_PATH)/../lib/stubs/drm/
 
 # set local libraries
 IGT_LOCAL_STATIC_LIBRARIES := libintel_gpu_tools
diff --git a/tools/Android.mk b/tools/Android.mk
index 0bad29c..5653572 100644
--- a/tools/Android.mk
+++ b/tools/Android.mk
@@ -30,7 +30,7 @@ define add_tool
 endif
 
 LOCAL_C_INCLUDES = $(LOCAL_PATH)/../lib
-LOCAL_C_INCLUDES += ${ANDROID_BUILD_TOP}/external/PRIVATE/drm/include/drm
+LOCAL_C_INCLUDES += $(LOCAL_PATH)/../lib/stubs/drm/
 LOCAL_C_INCLUDES += ${ANDROID_BUILD_TOP}/external/zlib
 
 LOCAL_MODULE := $1_tool
-- 
2.9.3

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

[Intel-gfx] [PATCH i-g-t 12/13] tools/Android.mk: Fix zlib inclusion

[Arkadiusz Hiler]

Add dependency on libz instead of doing path magic.

Signed-off-by: Arkadiusz Hiler 
---
 tools/Android.mk | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/Android.mk b/tools/Android.mk
index 5653572..96075c9 100644
--- a/tools/Android.mk
+++ b/tools/Android.mk
@@ -29,9 +29,8 @@ define add_tool
 LOCAL_LDFLAGS += $($(1)_LDFLAGS)
 endif
 
-LOCAL_C_INCLUDES = $(LOCAL_PATH)/../lib
-LOCAL_C_INCLUDES += $(LOCAL_PATH)/../lib/stubs/drm/
-LOCAL_C_INCLUDES += ${ANDROID_BUILD_TOP}/external/zlib
+LOCAL_C_INCLUDES = $(LOCAL_PATH)/../lib \
+   $(LOCAL_PATH)/../lib/stubs/drm/
 
 LOCAL_MODULE := $1_tool
 LOCAL_MODULE_TAGS := optional
@@ -41,7 +40,8 @@ define add_tool
 LOCAL_SHARED_LIBRARIES := libpciaccess  \
   libkmod   \
   libdrm\
-  libdrm_intel
+  libdrm_intel \
+  libz
 
 # Tools dir on host
 LOCAL_MODULE_PATH := $(TARGET_OUT_VENDOR)/$(LOCAL_TOOLS_DIR)
-- 
2.9.3

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

[Intel-gfx] [PATCH i-g-t 08/13] benchmarks/Android.mk: Add gem_latency to skip list

[Arkadiusz Hiler]

AOSP, as of this commit, does not include libdrm with fence defines.

Signed-off-by: Arkadiusz Hiler 
---
 benchmarks/Android.mk | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/benchmarks/Android.mk b/benchmarks/Android.mk
index c0fa09f..a790ec7 100644
--- a/benchmarks/Android.mk
+++ b/benchmarks/Android.mk
@@ -34,7 +34,9 @@ endef
 
 ##
 
-benchmark_list := $(benchmarks_prog_list)
+skip_benchmark_list = gem_latency
+
+benchmark_list := $(filter-out $(skip_benchmark_list),$(benchmarks_prog_list))
 
 ifeq ($(HAVE_LIBDRM_INTEL),true)
 benchmark_list += $(LIBDRM_INTEL_BENCHMARKS)
-- 
2.9.3

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

[Intel-gfx] [PATCH i-g-t 13/13] tests/gem_exec_nop: Disable headless subtest on cairoless Android

[Arkadiusz Hiler]

Currently whole igt_kms.c is disabled while compiling on Android without
cairo, so this tests does not compile.

There should be cleaner a way to disable only cairo dependant parts
which should allow us to enable at least some of the KMS tests, but
that's a bigger rework for another time.

Signed-off-by: Arkadiusz Hiler 
---
 lib/Android.mk   | 1 +
 tests/gem_exec_nop.c | 4 
 2 files changed, 5 insertions(+)

diff --git a/lib/Android.mk b/lib/Android.mk
index 31f88be..dc538b8 100644
--- a/lib/Android.mk
+++ b/lib/Android.mk
@@ -38,6 +38,7 @@ ifeq ("${ANDROID_HAS_CAIRO}", "1")
 LOCAL_C_INCLUDES += $(ANDROID_BUILD_TOP)/external/cairo-1.12.16/src
 LOCAL_CFLAGS += -DANDROID_HAS_CAIRO=1 -DIGT_DATADIR=\".\" 
-DIGT_SRCDIR=\".\"
 else
+
 skip_lib_list := \
 igt_kms.c \
 igt_kms.h \
diff --git a/tests/gem_exec_nop.c b/tests/gem_exec_nop.c
index 66c2fc1..967caef 100644
--- a/tests/gem_exec_nop.c
+++ b/tests/gem_exec_nop.c
@@ -138,6 +138,7 @@ stable_nop_on_ring(int fd, uint32_t handle, unsigned int 
engine,
return n;
 }
 
+#if (!defined(ANDROID)) || (defined(ANDROID) && ANDROID_HAS_CAIRO)
 #define assert_within_epsilon(x, ref, tolerance) \
 igt_assert_f((x) <= (1.0 + tolerance) * ref && \
  (x) >= (1.0 - tolerance) * ref, \
@@ -178,6 +179,7 @@ static void headless(int fd, uint32_t handle)
/* check that the two execution speeds are roughly the same */
assert_within_epsilon(n_headless, n_display, 0.1f);
 }
+#endif
 
 static bool ignore_engine(int fd, unsigned engine)
 {
@@ -561,8 +563,10 @@ igt_main
igt_subtest("context-sequential")
sequential(device, handle, FORKED | CONTEXT, 150);
 
+#if (!defined(ANDROID)) || (defined(ANDROID) && ANDROID_HAS_CAIRO)
igt_subtest("headless")
headless(device, handle);
+#endif
 
igt_fixture {
igt_stop_hang_detector();
-- 
2.9.3

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

[Intel-gfx] [PATCH i-g-t 10/13] Android.mk: Filter out *.h from src files

[Arkadiusz Hiler]

Newer Android's build system complains about unused files if we leave
those there.

Signed-off-by: Arkadiusz Hiler 
---
 lib/Android.mk   | 2 +-
 tools/Android.mk | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/Android.mk b/lib/Android.mk
index 0596e4a..003ade5 100644
--- a/lib/Android.mk
+++ b/lib/Android.mk
@@ -45,7 +45,7 @@ skip_lib_list := \
 -DANDROID_HAS_CAIRO=0
 endif
 
-LOCAL_SRC_FILES := $(filter-out $(skip_lib_list),$(lib_source_list))
+LOCAL_SRC_FILES := $(filter-out %.h $(skip_lib_list),$(lib_source_list))
 
 include $(BUILD_STATIC_LIBRARY)
 
diff --git a/tools/Android.mk b/tools/Android.mk
index a8e649b..0bad29c 100644
--- a/tools/Android.mk
+++ b/tools/Android.mk
@@ -12,7 +12,7 @@ define add_tool
 ifeq ($($(1)_SOURCES),)
 LOCAL_SRC_FILES := $1.c
 else
-LOCAL_SRC_FILES := $($(1)_SOURCES)
+LOCAL_SRC_FILES := $(filter-out %.h,$($(1)_SOURCES))
 endif
 
 LOCAL_CFLAGS += -DHAVE_TERMIOS_H
-- 
2.9.3

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

[Intel-gfx] [PATCH i-g-t 06/13] tools/Android.mk: Add guc_logger and l3_parity skip list

[Arkadiusz Hiler]

Those tools does not build on Android due to "Linux-only" dependencies.

Let's blacklist them for now.

Signed-off-by: Arkadiusz Hiler 
---
 tools/Android.mk | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/Android.mk b/tools/Android.mk
index 6cdedeb..0602e8c 100644
--- a/tools/Android.mk
+++ b/tools/Android.mk
@@ -59,6 +59,8 @@ bin_PROGRAMS := $(tools_prog_lists)
 
 skip_tools_list := \
 intel_framebuffer_dump \
+intel_guc_logger \
+intel_l3_parity \
 intel_reg_dumper \
 intel_vga_read \
 intel_vga_write
-- 
2.9.3

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

[Intel-gfx] [PATCH i-g-t 03/13] lib/igt_aux: Include unistd.h for gettid() on Android

[Arkadiusz Hiler]

We define gettid() using syscall() because glibc does not provide a
wrapper.

Android's bionic got the syscall covered though.

Signed-off-by: Arkadiusz Hiler 
---
 lib/igt_aux.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/lib/igt_aux.h b/lib/igt_aux.h
index e62858e..54b9716 100644
--- a/lib/igt_aux.h
+++ b/lib/igt_aux.h
@@ -43,7 +43,12 @@ extern int num_trash_bos;
 #define NSEC_PER_SEC (1000*USEC_PER_SEC)
 
 /* signal interrupt helpers */
+#ifdef ANDROID
+#include  /* on Android bionic has this implemented */
+#else
 #define gettid() syscall(__NR_gettid)
+#endif
+
 #define sigev_notify_thread_id _sigev_un._tid
 
 /* auxialiary igt helpers from igt_aux.c */
-- 
2.9.3

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

[Intel-gfx] [PATCH i-g-t 02/13] Make conditions on HAVE_UDEV consistent

[Arkadiusz Hiler]

We have a lot of `#ifdef HAVE_UDEV` and ` #if HAVE_UDEV` all over the
place, but ifdef and if have a slightly different semantics.

Let make it consistent by using #ifdefs only.

Signed-off-by: Arkadiusz Hiler 
---
 lib/igt_aux.c  | 2 +-
 tests/testdisplay_hotplug.c| 2 +-
 tools/intel_l3_parity.c| 2 +-
 tools/intel_l3_parity.h| 2 +-
 tools/intel_l3_udev_listener.c | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/lib/igt_aux.c b/lib/igt_aux.c
index 1222806..2ec6b78 100644
--- a/lib/igt_aux.c
+++ b/lib/igt_aux.c
@@ -388,7 +388,7 @@ void igt_stop_shrink_helper(void)
igt_stop_helper(&shrink_helper);
 }
 
-#if HAVE_UDEV
+#ifdef HAVE_UDEV
 #include 
 
 static struct igt_helper_process hang_detector;
diff --git a/tests/testdisplay_hotplug.c b/tests/testdisplay_hotplug.c
index 3b900ca..cf15511 100644
--- a/tests/testdisplay_hotplug.c
+++ b/tests/testdisplay_hotplug.c
@@ -34,7 +34,7 @@
 #endif
 
 
-#if HAVE_UDEV
+#ifdef HAVE_UDEV
 #include 
 static struct udev_monitor *uevent_monitor;
 static struct udev *udev;
diff --git a/tools/intel_l3_parity.c b/tools/intel_l3_parity.c
index dce7f32..eb00c50 100644
--- a/tools/intel_l3_parity.c
+++ b/tools/intel_l3_parity.c
@@ -42,7 +42,7 @@
 #ifdef HAVE_CONFIG_H
 #include "config.h"
 #endif
-#if HAVE_UDEV
+#ifdef HAVE_UDEV
 #include 
 #include 
 #endif
diff --git a/tools/intel_l3_parity.h b/tools/intel_l3_parity.h
index 65697c4..759c4f4 100644
--- a/tools/intel_l3_parity.h
+++ b/tools/intel_l3_parity.h
@@ -18,7 +18,7 @@ struct l3_location {
uint8_t subbank;
 };
 
-#if HAVE_UDEV
+#ifdef HAVE_UDEV
 int l3_uevent_setup(struct l3_parity *par);
 /* Listens (blocks) for an l3 parity event. Returns the location of the error. 
*/
 int l3_listen(struct l3_parity *par, bool daemon, struct l3_location *loc);
diff --git a/tools/intel_l3_udev_listener.c b/tools/intel_l3_udev_listener.c
index 0b94c1c..270bfff 100644
--- a/tools/intel_l3_udev_listener.c
+++ b/tools/intel_l3_udev_listener.c
@@ -25,7 +25,7 @@
 #include "config.h"
 #endif
 
-#if HAVE_UDEV
+#ifdef HAVE_UDEV
 #include 
 #ifndef _GNU_SOURCE
 #define _GNU_SOURCE
-- 
2.9.3

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

[Intel-gfx] [PATCH i-g-t 01/13] tests/drm_import_export: Include {i915_, }drm.h properly

[Arkadiusz Hiler]

Using `libdrm/` impairs compatibility with android build system and
pkg-config manages -I for us on regular distros.

Signed-off-by: Arkadiusz Hiler 
---
 tests/drm_import_export.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/drm_import_export.c b/tests/drm_import_export.c
index cfe5f6d..f1234bd 100644
--- a/tests/drm_import_export.c
+++ b/tests/drm_import_export.c
@@ -32,8 +32,8 @@
 #include 
 #include 
 #include 
-#include 
-#include 
+#include 
+#include 
 #include 
 #include 
 #include 
-- 
2.9.3

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

[Intel-gfx] [PATCH i-g-t 00/13] Fix IGTs for Android

[Arkadiusz Hiler]

IGTs are broken for Android since the introduction of dependency on procps. Over
time other incompatibilities built up.

I took the liberty to fix some of the issues, workaround couple of others and
blacklist heavily incompatible tools/tests.

It builds on (almost) vanilla AOSP now.

Github: 
Howto:  

DEP1: 
DEP2: 

We should include a note on Android compatibility in the README and do
"continuous compilation" of the patches as they arrive on the mailing list,
otherwise this **will get broken again soon**.

This is long as it is, but not complete yet.

Here are some of more obvious TODOs:
 * introduce something like IGT_HAS_CAIRO define for convenience
 * revise igt_kms dependency on cairo and enable everything what is independent
 * revise kms tests and do the above
 * review all things that are disabled on Android and try to enable them
 * do something less ugly with config.h generation on Android

Cc: Antonio Argenziano 
Cc: Vinay Belgaumkar 
Cc: Chris Wilson 
Cc: Robert Foss 

Arkadiusz Hiler (13):
  tests/drm_import_export: Include {i915_,}drm.h properly
  Make conditions on HAVE_UDEV consistent
  lib/igt_aux: Include unistd.h for gettid() on Android
  lib/igt_aux: Make procps optional
  chamelium: Fix build issues on Android
  tools/Android.mk: Add guc_logger and l3_parity skip list
  tests/Android.mk: Add perf to skip list
  benchmarks/Android.mk: Add gem_latency to skip list
  Android.mk: Fix libkmod use
  Android.mk: Filter out *.h from src files
  Android.mk: Use drm stubs
  tools/Android.mk: Fix zlib inclusion
  tests/gem_exec_nop: Disable headless subtest on cairoless Android

 benchmarks/Android.mk  |  9 +++--
 configure.ac   |  6 +-
 demos/Android.mk   |  3 ++-
 lib/Android.mk |  8 +---
 lib/Makefile.am|  7 +++
 lib/Makefile.sources   |  7 ---
 lib/igt.h  |  2 ++
 lib/igt_aux.c  | 26 ++
 lib/igt_aux.h  |  5 +
 lib/igt_chamelium.h|  3 +++
 lib/igt_kmod.h |  4 
 lib/tests/Android.mk   |  4 ++--
 tests/Android.mk   |  9 +
 tests/Makefile.am  |  6 ++
 tests/Makefile.sources |  6 --
 tests/drm_import_export.c  |  4 ++--
 tests/gem_exec_nop.c   |  4 
 tests/testdisplay_hotplug.c|  2 +-
 tools/Android.mk   | 14 +-
 tools/intel_l3_parity.c|  2 +-
 tools/intel_l3_parity.h|  2 +-
 tools/intel_l3_udev_listener.c |  2 +-
 22 files changed, 94 insertions(+), 41 deletions(-)

-- 
2.9.3

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

Re: [Intel-gfx] [PATCH v6 05/20] drm/i915/tdr: Add support for per engine reset recovery

[Chris Wilson]

On Tue, Apr 18, 2017 at 01:23:20PM -0700, Michel Thierry wrote:
> From: Arun Siluvery 
> 
> This change implements support for per-engine reset as an initial, less
> intrusive hang recovery option to be attempted before falling back to the
> legacy full GPU reset recovery mode if necessary. This is only supported
> from Gen8 onwards.
> 
> Hangchecker determines which engines are hung and invokes error handler to
> recover from it. Error handler schedules recovery for each of those engines
> that are hung. The recovery procedure is as follows,
>  - identifies the request that caused the hang and it is dropped
>  - force engine to idle: this is done by issuing a reset request
>  - reset and re-init engine
>  - restart submissions to the engine
> 
> If engine reset fails then we fall back to heavy weight full gpu reset
> which resets all engines and reinitiazes complete state of HW and SW.
> 
> v2: Rebase.
> v3: s/*engine_reset*/*reset_engine*/; freeze engine and irqs before
> calling i915_gem_reset_engine (Chris).
> v4: Rebase, modify i915_gem_reset_prepare to use a ring mask and
> reuse the function for reset_engine.
> v5: intel_reset_engine_start/cancel instead of request/unrequest_reset.
> v6: Clean up reset_engine function to not require mutex, i.e. no need to call
> revoke/restore_fences and _retire_requests (Chris).
> 
> Cc: Chris Wilson 
> Cc: Mika Kuoppala 
> Signed-off-by: Tomas Elf 
> Signed-off-by: Arun Siluvery 
> Signed-off-by: Michel Thierry 
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 76 --
>  drivers/gpu/drm/i915/i915_drv.h | 12 +++-
>  drivers/gpu/drm/i915/i915_gem.c | 97 
> +++--
>  drivers/gpu/drm/i915/i915_gem_request.c |  2 +-
>  drivers/gpu/drm/i915/intel_uncore.c | 20 +++
>  5 files changed, 158 insertions(+), 49 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index e03d0643dbd6..634893cd93b3 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1810,7 +1810,7 @@ void i915_reset(struct drm_i915_private *dev_priv)
>  
>   pr_notice("drm/i915: Resetting chip after gpu hang\n");
>   disable_irq(dev_priv->drm.irq);
> - ret = i915_gem_reset_prepare(dev_priv);
> + ret = i915_gem_reset_prepare(dev_priv, ALL_ENGINES);
>   if (ret) {
>   DRM_ERROR("GPU recovery failed\n");
>   intel_gpu_reset(dev_priv, ALL_ENGINES);
> @@ -1852,7 +1852,7 @@ void i915_reset(struct drm_i915_private *dev_priv)
>   i915_queue_hangcheck(dev_priv);
>  
>  finish:
> - i915_gem_reset_finish(dev_priv);
> + i915_gem_reset_finish(dev_priv, ALL_ENGINES);
>   enable_irq(dev_priv->drm.irq);
>  
>  wakeup:
> @@ -1871,11 +1871,79 @@ void i915_reset(struct drm_i915_private *dev_priv)
>   *
>   * Reset a specific GPU engine. Useful if a hang is detected.
>   * Returns zero on successful reset or otherwise an error code.
> + *
> + * Procedure is:
> + *  - identifies the request that caused the hang and it is dropped
> + *  - force engine to idle: this is done by issuing a reset request
> + *  - reset engine
> + *  - restart submissions to the engine
>   */
>  int i915_reset_engine(struct intel_engine_cs *engine)
>  {
> - /* FIXME: replace me with engine reset sequence */
> - return -ENODEV;
> + int ret;
> + struct drm_i915_private *dev_priv = engine->i915;
> + struct i915_gpu_error *error = &dev_priv->gpu_error;
> +
> + GEM_BUG_ON(!test_bit(I915_RESET_BACKOFF, &error->flags));
> +
> + DRM_DEBUG_DRIVER("resetting %s\n", engine->name);
> +
> + /*
> +  * We need to first idle the engine by issuing a reset request,
> +  * then perform soft reset and re-initialize hw state, for all of
> +  * this GT power need to be awake so ensure it does throughout the
> +  * process
> +  */
> + intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);

Hmm, what path did we take to get here without taking rpm? I thought I
had fixed the last offender.

> + disable_irq(dev_priv->drm.irq);

I am 99% certain that we don't need to disable_irq() now for per-engine
reset... I'd keep it in the global reset as simple paranoia.

> + ret = i915_gem_reset_prepare_engine(engine);
> + if (ret) {
> + DRM_ERROR("Previous reset failed - promote to full reset\n");
> + goto error;
> + }
> +
> + /*
> +  * the request that caused the hang is stuck on elsp, identify the
> +  * active request and drop it, adjust head to skip the offending
> +  * request to resume executing remaining requests in the queue.
> +  */

Hmm. Interesting. This relies on i915_gem_retire_requests() (i.e.
struct_mutex) to skip replaying innocent requests, but here we should be
asserting that we do have the hung request.

i.e.
request = i915_gem_find_active_request(engine);
if (!request)
goto skip.

Bonus points for tying that into i915_gem_reset_prepare

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

[Rafael J. Wysocki]

On Wed, Apr 19, 2017 at 10:59 AM, Hans de Goede  wrote:
> Hi,
>
>
> On 18-04-17 15:34, Rafael J. Wysocki wrote:
>>
>> On Tue, Apr 18, 2017 at 1:54 PM, Hans de Goede 
>> wrote:
>>>
>>> Several Cherry Trail devices (all of which ship with Windows 10) hide the
>>> LPSS PWM controller in ACPI, typically the _STA method looks like this:
>>>
>>> Method (_STA, 0, NotSerialized)  // _STA: Status
>>> {
>>> If (OSID == One)
>>> {
>>> Return (Zero)
>>> }
>>>
>>> Return (0x0F)
>>> }
>>>
>>> Where OSID is some dark magic seen in all Cherry Trail ACPI tables making
>>> the machine behave differently depending on which OS it *thinks* it is
>>> booting, this gets set in a number of ways which we cannot control, on
>>> some newer machines it simple hardcoded to "One" aka win10.
>>>
>>> This causes the PWM controller to get hidden, which means Linux cannot
>>> control the backlight level on cht based tablets / laptops.
>>>
>>> Since loading the driver for this does no harm (the only in kernel user
>>> of it is the i915 driver, which will only use it when it needs it), this
>>> commit makes acpi_bus_get_status() always set status to ACPI_STA_DEFAULT
>>> for the 80862288 device, fixing the lack of backlight control.
>>>
>>> Signed-off-by: Hans de Goede 
>>> ---
>>> Changes in v2:
>>> -Use pr_debug instead of ACPI_DEBUG_PRINT
>>> Changes in v3:
>>> -Un-inline acpi_set_device_status and do the always_present_device_ids
>>>  table check inside the un-inlined version of it
>>> Changes in v4:
>>> -Use dev_info instead of pr_debug
>>> -Not only check for ACPI HID but also for CPU (SoC) model so as to not
>>>  for devices present on other models then for which the quirk is intended
>>> and
>>>  to avoid enabling unrelated ACPI devices which happen to use the same
>>> HID
>>> Changes in v5:
>>> -Only do the dev_info once per device (acpi_set_device_status gets called
>>>  multiple times per device during boot)
>>> Changes in v6:
>>> -Allow specifying more then one CPU-model for a single HID
>>> -Not only match the HID but also the UID, like on Cherry Trail, on some
>>> Bay
>>>  Trail Windows 10 tablets we need to enable the PWM controller to get
>>> working
>>>  backlight even though _STA returns 0. The Bay Trail SoC has 2 PWM
>>> controllers
>>>  and we only need the first one. UID matching will allows adding an entry
>>> for
>>>  Bay Trail which only enables the first PWM controller
>>> ---
>>>  drivers/acpi/bus.c  | 65
>>> +
>>>  include/acpi/acpi_bus.h |  6 +
>>>  2 files changed, 66 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
>>> index 34fbe02..eb30630 100644
>>> --- a/drivers/acpi/bus.c
>>> +++ b/drivers/acpi/bus.c
>>> @@ -34,6 +34,8 @@
>>>  #include 
>>>  #include 
>>>  #ifdef CONFIG_X86
>>> +#include 
>>> +#include 
>>>  #include 
>>>  #endif
>>>  #include 
>>> @@ -132,6 +134,69 @@ int acpi_bus_get_status(struct acpi_device *device)
>>>  }
>>>  EXPORT_SYMBOL(acpi_bus_get_status);
>>>
>>> +#ifdef CONFIG_X86
>>> +/*
>>> + * Some ACPI devices are hidden (status == 0x0) in recent BIOS-es
>>> because
>>> + * some recent Windows drivers bind to one device but poke at multiple
>>> + * devices at the same time, so the others get hidden.
>>> + * We work around this by always reporting ACPI_STA_DEFAULT for these
>>> + * devices. Note this MUST only be done for devices where this is safe.
>>> + *
>>> + * This forcing of devices to be present is limited to specific CPU
>>> (SoC)
>>> + * models both to avoid potentially causing trouble on other models and
>>> + * because some HIDs are re-used on different SoCs for completely
>>> + * different devices.
>>> + */
>>> +struct always_present_device_id {
>>> +   struct acpi_device_id hid[2];
>>> +   struct x86_cpu_id cpu_ids[2];
>>
>>
>> This really is x86-specific, so it should go into somewhere like
>> arch/x86/kernel/acpi/ or drivers/acpi/x86/ (not present yet).
>
>
> Ok, but then how do you want to hook this up, before you said
> that you wanted to deal with this in acpi_set_device_status(),
> which belongs in drivers/acpi/bus.c, do you want the x86
> code to provide something like a
>
> bool acpi_device_always_present(struct acpi_device *adev) {
> }
>
> Helper function and use that in the drivers/acpi/bus.c
> acpi_set_device_status() implementation ?

Yes, something like that.

In a header file you can make it depend on CONFIG_X86 and provide and
empty static inline stub for the "not defined" case.

>>
>>> +   const char *uid;
>>> +};
>>> +
>>> +#define ICPU(model){ X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, }
>>> +
>>> +#define ENTRY(hid, uid, cpu_models) {  \
>>> +   { { hid, }, {} },   \
>>> +   { cpu_models, {} }, \
>>> +   uid,   

Re: [Intel-gfx] [PATCH v6 14/20] drm/i915/guc: Add support for reset engine using GuC commands

[Chris Wilson]

On Tue, Apr 18, 2017 at 01:23:29PM -0700, Michel Thierry wrote:
> This patch adds per engine reset and recovery (TDR) support when GuC is
> used to submit workloads to GPU.
> 
> In the case of i915 directly submission to ELSP, driver manages hang
> detection, recovery and resubmission. With GuC submission these tasks
> are shared between driver and GuC. i915 is still responsible for detecting
> a hang, and when it does it only requests GuC to reset that Engine. GuC
> internally manages acquiring forcewake and idling the engine before actually
> resetting it.
> 
> Once the reset is successful, i915 takes over again and handles resubmission.
> The scheduler in i915 knows which requests are pending so after resetting
> a engine, pending workloads/requests are resubmitted again.
> 
> v2: s/i915_guc_request_engine_reset/i915_guc_reset_engine/ to match the
> non-guc funtion names.
> 
> Signed-off-by: Arun Siluvery 
> Signed-off-by: Jeff McGee 
> Signed-off-by: Michel Thierry 
> ---
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 7df278fe492e..6295760098a1 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -1176,14 +1176,15 @@ static int gen8_init_common_ring(struct 
> intel_engine_cs *engine)
>  
>   /* After a GPU reset, we may have requests to replay */
>   clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
> - if (!i915.enable_guc_submission && !execlists_elsp_idle(engine)) {
> + if (!execlists_elsp_idle(engine)) {
>   DRM_DEBUG_DRIVER("Restarting %s from requests [0x%x, 0x%x]\n",
>engine->name,
>port_seqno(&engine->execlist_port[0]),
>port_seqno(&engine->execlist_port[1]));
>   engine->execlist_port[0].count = 0;
>   engine->execlist_port[1].count = 0;
> - execlists_submit_ports(engine);
> + if (!dev_priv->guc.execbuf_client)
> + execlists_submit_ports(engine);

Not sure what you were intending to do here as this only resets the
submission count -- which is not used by guc dequeue. Some merit in the
making the code look similar, certainly adds the dbg message but I think
it is unrelated to the rest of the patch.
-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 v6 16/20] drm/i915: Watchdog timeout: IRQ handler for gen8+

[Chris Wilson]

On Tue, Apr 18, 2017 at 01:23:31PM -0700, Michel Thierry wrote:
> *** General ***
> 
> Watchdog timeout (or "media engine reset") is a feature that allows
> userland applications to enable hang detection on individual batch buffers.
> The detection mechanism itself is mostly bound to the hardware and the only
> thing that the driver needs to do to support this form of hang detection
> is to implement the interrupt handling support as well as watchdog command
> emission before and after the emitted batch buffer start instruction in the
> ring buffer.
> 
> The principle of the hang detection mechanism is as follows:
> 
> 1. Once the decision has been made to enable watchdog timeout for a
> particular batch buffer and the driver is in the process of emitting the
> batch buffer start instruction into the ring buffer it also emits a
> watchdog timer start instruction before and a watchdog timer cancellation
> instruction after the batch buffer start instruction in the ring buffer.
> 
> 2. Once the GPU execution reaches the watchdog timer start instruction
> the hardware watchdog counter is started by the hardware. The counter
> keeps counting until either reaching a previously configured threshold
> value or the timer cancellation instruction is executed.
> 
> 2a. If the counter reaches the threshold value the hardware fires a
> watchdog interrupt that is picked up by the watchdog interrupt handler.
> This means that a hang has been detected and the driver needs to deal with
> it the same way it would deal with a engine hang detected by the periodic
> hang checker. The only difference between the two is that we already blamed
> the active request (to ensure an engine reset).
> 
> 2b. If the batch buffer completes and the execution reaches the watchdog
> cancellation instruction before the watchdog counter reaches its
> threshold value the watchdog is cancelled and nothing more comes of it.
> No hang is detected.
> 
> Note about future interaction with preemption: Preemption could happen
> in a command sequence prior to watchdog counter getting disabled,
> resulting in watchdog being triggered following preemption. The driver will
> need to explicitly disable the watchdog counter as part of the
> preemption sequence.

Does MI_ARB_ON_OFF do the trick? Shouldn't we basically be only turning
preemption on for the user buffers as it just causes hassle if we allow
preemption in our preamble + breadcrumb. (And there's little point in
preempting in the flushes.)

> *** This patch introduces: ***
> 
> 1. IRQ handler code for watchdog timeout allowing direct hang recovery
> based on hardware-driven hang detection, which then integrates directly
> with the hang recovery path. This is independent of having per-engine reset
> or just full gpu reset.
> 
> 2. Watchdog specific register information.
> 
> Currently the render engine and all available media engines support
> watchdog timeout (VECS is only supported in GEN9). The specifications elude
> to the BCS engine being supported but that is currently not supported by
> this commit.
> 
> Note that the value to stop the counter is different between render and
> non-render engines in GEN8; GEN9 onwards it's the same.

Should mention the choice to piggyback the current hangcheck + capture
scheme.

> + if (iir & (GT_GEN8_WATCHDOG_INTERRUPT << test_shift)) {
> + tasklet_schedule(&engine->watchdog_tasklet);
> + }

Kill unwanted braces.

> +#define GEN8_WATCHDOG_1000US 0x2ee0 //XXX: Temp, replace with helper function
> +static void gen8_watchdog_irq_handler(unsigned long data)
> +{
> + struct intel_engine_cs *engine = (struct intel_engine_cs *)data;
> + struct drm_i915_private *dev_priv = engine->i915;
> + u32 current_seqno;
> +
> + intel_uncore_forcewake_get(dev_priv, engine->fw_domains);
> +
> + /* Stop the counter to prevent further timeout interrupts */
> + I915_WRITE_FW(RING_CNTR(engine->mmio_base), 
> get_watchdog_disable(engine));
> +
> + current_seqno = intel_engine_get_seqno(engine);
> +
> + /* did the request complete after the timer expired? */
> + if (intel_engine_last_submit(engine) == current_seqno)
> + goto fw_put;
> +
> + if (engine->hangcheck.watchdog == current_seqno) {
> + /* Make sure the active request will be marked as guilty */
> + engine->hangcheck.stalled = true;
> + engine->hangcheck.seqno = intel_engine_get_seqno(engine);

Use current_seqno again. intel_engine_get_seqno() may have just changed.
-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 i-g-t] tests/meta_test: Add a meta test for sanity checks of CI systems

[Lofstedt, Marta]

> -Original Message-
> From: Latvala, Petri
> Sent: Wednesday, April 19, 2017 12:08 PM
> To: Lofstedt, Marta 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [PATCH i-g-t] tests/meta_test: Add a meta test for sanity checks
> of CI systems
> 
> On Wed, Apr 05, 2017 at 01:11:53PM +0300, Marta Lofstedt wrote:
> > The intention of this test is use it to test that the CI system that
> > runs IGT is collecting the results correctly.
> >
> > For: VIZ-10281
> >
> > Signed-off-by: Marta Lofstedt 
> > ---
> >  tests/Makefile.sources   |   1 +
> >  tests/intel-ci/meta.testlist |   7 +++
> >  tests/meta_test.c| 145
> +++
> >  3 files changed, 153 insertions(+)
> >  create mode 100644 tests/intel-ci/meta.testlist  create mode 100644
> > tests/meta_test.c
> >
> > diff --git a/tests/Makefile.sources b/tests/Makefile.sources index
> > 45c21a0..7fa9b8f 100644
> > --- a/tests/Makefile.sources
> > +++ b/tests/Makefile.sources
> > @@ -143,6 +143,7 @@ TESTS_progs_M = \
> > template \
> > vgem_basic \
> > vgem_slow \
> > +   meta_test \
> > $(NULL)
> >
> >  if HAVE_CHAMELIUM
> > diff --git a/tests/intel-ci/meta.testlist
> > b/tests/intel-ci/meta.testlist new file mode 100644 index
> > 000..b3e2923
> > --- /dev/null
> > +++ b/tests/intel-ci/meta.testlist
> > @@ -0,0 +1,7 @@
> > +igt@meta_test@pass-result
> > +igt@meta_test@fail-result
> > +igt@meta_test@dmesg-pass
> > +igt@meta_test@dmesg-warn
> > +igt@meta_test@user-crash
> > +igt@meta_test@piglit-timeout
> > +igt@meta_test@generate-panic
> > diff --git a/tests/meta_test.c b/tests/meta_test.c new file mode
> > 100644 index 000..8a420ba
> > --- /dev/null
> > +++ b/tests/meta_test.c
> > @@ -0,0 +1,145 @@
> > +/*
> > + * Copyright (c) 2017 Intel Corporation
> > + *
> > + * Permission is hereby granted, free of charge, to any person
> > +obtaining a
> > + * copy of this software and associated documentation files (the
> > +"Software"),
> > + * to deal in the Software without restriction, including without
> > +limitation
> > + * the rights to use, copy, modify, merge, publish, distribute,
> > +sublicense,
> > + * and/or sell copies of the Software, and to permit persons to whom
> > +the
> > + * Software is furnished to do so, subject to the following conditions:
> > + *
> > + * The above copyright notice and this permission notice (including
> > +the next
> > + * paragraph) shall be included in all copies or substantial portions
> > +of the
> > + * Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
> KIND,
> > +EXPRESS OR
> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> > +MERCHANTABILITY,
> > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN
> NO EVENT
> > +SHALL
> > + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
> DAMAGES
> > +OR OTHER
> > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
> OTHERWISE,
> > +ARISING
> > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE
> OR
> > +OTHER DEALINGS
> > + * IN THE SOFTWARE.
> > + *
> > + */
> > +
> > +#include 
> > +#include 
> > +#include "igt.h"
> > +
> > +/*
> > + * The purpose of this test is to test the CI system that we have
> > + * for running the tests. The test should generate all possible
> > + * exit states for igt tests.
> > + *
> > + * Possible exit-states of igt tests:
> > + * 1. pass - subtest: pass-result
> > + * 2. fail - subtest: fail-result
> > + * 3. dmesg warn - subtest: dmesg-fail,
> > + *  subtest: dmesg-pass is a sanity check for the dmesg-fail.
> 
> 
> Add some further explanation here about the purpose and why the test
> does what it does: The purpose is to check that certain kernel log activity 
> gets
> correctly reported in the test result, and that normal activity doesn't?
> 
> 
> > + * 4. crash - subtest: user-crash
> > + * 5. piglit timeout - subtest: piglit-timeout
> > + * 6. incomplete - subtest: generate-panic
> > + *  NOTE: inorder for this to generate the incomplete state
> > + *  the kernel must be configured to reboot on panic.
> > + *  NOTE: if the tested CI system have features such as
> > + *  PSTORE and/or kexec/kdump enabled. This test could be
> > + *  used to make sure that the CI system stores the generated
> > + *  log/dumps as expected.
> > + * 7. incomplete - where user hang is not caught by piglit timeout.
> > + *  This would be caught by a user-side softdog daemon,
> > + *  such as owatch by ezbench. However, I don't know
> > + *  how to trigger this state, so it will not be tested.
> > + * 8. incomplete - system requires hard reboot :
> > + *  This state could be triggered by calling an evil kernel
> > + *  module that was developed hang the system. Such
> > + *  a module will not be developed for this purpose,
> > + *  so this "exit state" will not be tested.
> > + *
> > + * TODO: If this test was deployed on a CI system that
> > + * was abl

Re: [Intel-gfx] [PATCH 27/27] drm/i915/scheduler: Support user-defined priorities

[Chris Wilson]

On Wed, Apr 19, 2017 at 10:41:43AM +0100, Chris Wilson wrote:
> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> index f43a22ae955b..200f2cf393b2 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -395,6 +395,8 @@ typedef struct drm_i915_irq_wait {
>  
>  /* Query whether DRM_I915_GEM_EXECBUFFER2 supports user defined execution
>   * priorities and the driver will attempt to execute batches in priority 
> order.
> + * The initial priority for each batch is supplied by the context and is
> + * controlled via I915_CONTEXT_PARAM_PRIORITY.
>   */
>  #define I915_PARAM_HAS_SCHEDULER  41
>  #define I915_PARAM_HUC_STATUS 42
> @@ -1318,6 +1320,7 @@ struct drm_i915_gem_context_param {
>  #define I915_CONTEXT_PARAM_GTT_SIZE  0x3
>  #define I915_CONTEXT_PARAM_NO_ERROR_CAPTURE  0x4
>  #define I915_CONTEXT_PARAM_BANNABLE  0x5
> +#define I915_CONTEXT_PARAM_PRIORITY  0x6

Grr. Forgot to add min/max defines.

#define I915_CONTEXT_MAX_USER_PRIORITY  1023 /* inclusive */
#define I915_CONTEXT_DEFAULT_PRIORITY   0
#define I915_CONTEXT_MIN_USER_PRIORITY  -1023 /* inclusive */

Or should it be I915_CONTEXT_PRIORITY_MAX_USER etc?
-Chris

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

[Intel-gfx] [PATCH i-g-t v2] tests/meta_test: Add a meta test for sanity checks of CI systems

[Marta Lofstedt]

From: Marta Löfstedt 

The intention of this test is use it to test that the CI system
that runs IGT is collecting the results correctly.

For: VIZ-10281

v2: minor edits

Signed-off-by: Marta Lofstedt 
Reviewed-by: Petri Latvala 
---
 tests/Makefile.sources   |   1 +
 tests/intel-ci/meta.testlist |   7 ++
 tests/meta_test.c| 149 +++
 3 files changed, 157 insertions(+)
 create mode 100644 tests/intel-ci/meta.testlist
 create mode 100644 tests/meta_test.c

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 45c21a0c..7fa9b8f2 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -143,6 +143,7 @@ TESTS_progs_M = \
template \
vgem_basic \
vgem_slow \
+   meta_test \
$(NULL)
 
 if HAVE_CHAMELIUM
diff --git a/tests/intel-ci/meta.testlist b/tests/intel-ci/meta.testlist
new file mode 100644
index ..b3e29235
--- /dev/null
+++ b/tests/intel-ci/meta.testlist
@@ -0,0 +1,7 @@
+igt@meta_test@pass-result
+igt@meta_test@fail-result
+igt@meta_test@dmesg-pass
+igt@meta_test@dmesg-warn
+igt@meta_test@user-crash
+igt@meta_test@piglit-timeout
+igt@meta_test@generate-panic
diff --git a/tests/meta_test.c b/tests/meta_test.c
new file mode 100644
index ..e09efba0
--- /dev/null
+++ b/tests/meta_test.c
@@ -0,0 +1,149 @@
+/*
+ * Copyright © 2017 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include 
+#include 
+#include "igt.h"
+
+/*
+ * The purpose of this test is to test the CI system that we have
+ * for running the tests. The test should generate all possible
+ * exit states for igt tests.
+ *
+ * Possible exit-states of igt tests:
+ * 1. pass - subtest: pass-result
+ * 2. fail - subtest: fail-result
+ * 3. dmesg warn - subtest: dmesg-pass
+ *   - subtest: dmesg-warn
+ * The purpose is to check that certain kernel log activity
+ * gets correctly reported in the test result, and that normal
+ * activity doesn't.
+ * 4. crash - subtest: user-crash
+ * 5. piglit timeout - subtest: piglit-timeout
+ * 6. incomplete - subtest: generate-panic
+ *  NOTE: inorder for this to generate the incomplete state
+ *  the kernel must be configured to reboot on panic.
+ *  NOTE: if the tested CI system have features such as
+ *  PSTORE and/or kexec/kdump enabled. This test could be
+ *  used to make sure that the CI system stores the generated
+ *  log/dumps as expected.
+ * 7. incomplete - where user hang is not caught by piglit timeout.
+ *  This would be caught by a user-side softdog daemon,
+ *  such as owatch by ezbench. However, I don't know
+ *  how to trigger this state, so it will not be tested.
+ * 8. incomplete - system requires hard reboot :
+ *  This state could be triggered by calling an evil kernel
+ *  module that was developed hang the system. Such
+ *  a module will not be developed for this purpose,
+ *  so this "exit state" will not be tested.
+ *
+ * TODO: If this test was deployed on a CI system that
+ * was able to pick up testing again after reboot,
+ * such as ezbench, a post-analyze test should be added
+ * that collected and analyzed the result of the tests
+ * run before reboot.
+ */
+
+__attribute__((format(printf, 1, 2)))
+static void kmsg(const char *format, ...)
+#define KERN_EMER  "<0>"
+#define KERN_ALERT "<1>"
+#define KERN_CRIT  "<2>"
+#define KERN_ERR   "<3>"
+#define KERN_WARNING   "<4>"
+#define KERN_NOTICE"<5>"
+#define KERN_INFO  "<6>"
+#define KERN_DEBUG "<7>"
+{
+   va_list ap;
+   FILE *file;
+
+   file = fopen("/dev/kmsg", "w");
+   if (file == NULL)
+   return;
+
+   va_start(ap, format);
+   vfprintf(file, format, ap);
+   va_end(ap);
+   fclose(file);
+}
+
+static void test_result(bool result)
+{
+   igt_assert_eq(result, tr

Re: [Intel-gfx] [PATCH 16/22] xen-blkfront: Make use of the new sg_map helper function

[David Laight]

From: Logan Gunthorpe
> Sent: 13 April 2017 23:05
> Straightforward conversion to the new helper, except due to
> the lack of error path, we have to warn if unmapable memory
> is ever present in the sgl.
> 
> Signed-off-by: Logan Gunthorpe 
> ---
>  drivers/block/xen-blkfront.c | 33 +++--
>  1 file changed, 27 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 5067a0a..7dcf41d 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -807,8 +807,19 @@ static int blkif_queue_rw_req(struct request *req, 
> struct blkfront_ring_info *ri
>   BUG_ON(sg->offset + sg->length > PAGE_SIZE);
> 
>   if (setup.need_copy) {
> - setup.bvec_off = sg->offset;
> - setup.bvec_data = kmap_atomic(sg_page(sg));
> + setup.bvec_off = 0;
> + setup.bvec_data = sg_map(sg, SG_KMAP_ATOMIC);
> + if (IS_ERR(setup.bvec_data)) {
> + /*
> +  * This should really never happen unless
> +  * the code is changed to use memory that is
> +  * not mappable in the sg. Seeing there is a
> +  * questionable error path out of here,
> +  * we WARN.
> +  */
> + WARN(1, "Non-mappable memory used in sg!");
> + return 1;
> + }
...

Perhaps add a flag to mark failure as 'unexpected' and trace (and panic?)
inside sg_map().

David


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

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

[Hans de Goede]

Hi,

On 18-04-17 10:31, Andy Shevchenko wrote:

On Mon, 2017-04-10 at 17:49 +0200, Hans de Goede wrote:

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


CherryTrail
PWM
LPSS


All fixed.





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

Return (0x0F)
}

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

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

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



+#ifdef CONFIG_X86
+/*
+ * Some ACPI devices are hidden (status == 0x0) in recent BIOS-es
because
+ * some recent windows drivers bind to one device but poke at
multiple


Windows


Fixed for v6.


+ * devices at the same time, so the others get hidden.
+ * We work around this by always reporting ACPI_STA_DEFAULT for these
+ * devices. Note this MUST only be done for devices where this is
safe.
+ *
+ * This forcing of devices to be present is limited to specific CPU
(SoC)
+ * models both to avoid potentially causing trouble on other models
and
+ * because some HIDs are re-used on different SoCs for completely
+ * different devices.
+ */
+struct always_present_device_id {
+   struct acpi_device_id hid[2];
+   struct x86_cpu_id cpu_id[2];
+};
+



+#define ENTRY(hid, cpu_model) {



\
+   { { hid, }, {} },   
\



+   { { X86_VENDOR_INTEL, 6, cpu_model, X86_FEATURE_ANY, }, {} },
\


Can we use separate macro for this. i.e. ICPU() ?


Fixed for v5.


Perhaps at some point we might switch to set of generic ICPU()-like
macros.


Yes if something like a generic form of the ICPU macro ever becomes
available then switching to it would be a good idea.


Moreover, it seems you may change it to use only one existing structure

ICPU(model, hid)


+}
+
+static const struct always_present_device_id
always_present_device_ids[] = {
+   /*
+* Cherrytrail pwm directly poked by GPU driver in win10,
+* but Linux uses a separate pwm driver, harmless if not
used.
+*/
+   ENTRY("80862288", INTEL_FAM6_ATOM_AIRMONT),
+};
+#endif
+
+void acpi_set_device_status(struct acpi_device *adev, u32 sta)
+{
+   u32 *status = (u32 *)&adev->status;
+#ifdef CONFIG_X86
+   int i;
+
+   /* acpi_match_device_ids checks status, so start with default
*/
+   *status = ACPI_STA_DEFAULT;



+   for (i = 0; i < ARRAY_SIZE(always_present_device_ids); i++) {
+   if (acpi_match_device_ids(adev,
+   always_present_device_ids[i].hid) == 0 &&
+   x86_match_cpu(always_present_device_ids[i].cpu_id
)) {


I don't like this. It looks a bit hackish. If we need more, than one hid
per CPU, we might just supply an array


Note this started with just HID matching, later the cpu-id match
got added for 2 reasons:
-Extra safety check to not force enable devices on other models then for
 which the quirk is intended
-Some HIDs get re-used (by Intel) on different platforms for completely
 different devices. E.g. the INT0002 HID is used on both Intel Menlow
 for the Menlow thermal management extension and on Bay Trail / Cherry
 Trail for a "virtual gpio" controller which is involved in wakeup
 from suspend

Basically the HID is leading, as we want to have a quirk for a
specific HID to get enabled even if its _STA returns 0 and the CPU-ID
check is an extra check, so for v6 I've modified it to take an array
of cpu-ids, so that we do not need duplicate table entries for when
we want to check the same HID on 2 CPU models.

Regards,

Hans






ICPU(model, hids)


+   dev_info(&adev->dev, "Device [%s] is in
always present list setting status [%08x]\n",
+adev->pnp.bus_id, ACPI_STA_DEFAULT);
+   return;
+   }
+   }
+#endif



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

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/27] drm/i915/selftests: Allocate inode/file dynamically

[Patchwork]

== Series Details ==

Series: series starting with [01/27] drm/i915/selftests: Allocate inode/file 
dynamically
URL   : https://patchwork.freedesktop.org/series/23227/
State : failure

== Summary ==

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

Test gem_exec_fence:
Subgroup await-hang-default:
pass   -> INCOMPLETE (fi-ilk-650)
Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
fail   -> PASS   (fi-snb-2600) fdo#17

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:426s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:420s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:569s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:504s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:549s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:491s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:483s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:410s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:410s
fi-ilk-650   total:48   pass:27   dwarn:0   dfail:0   fail:0   skip:20 
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:491s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:471s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:450s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time:562s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:448s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:562s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:450s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:483s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:425s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:531s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:408s

05040c47d415b1621c0d64e40c0062890b854c9f drm-tip: 2017y-04m-19d-06h-48m-08s UTC 
integration manifest
f615350 drm/i915/scheduler: Support user-defined priorities
40273ef drm/i915: Async GPU relocation processing
910dcf5 drm/i915: Allow execbuffer to use the first object as the batch
4949570 drm/i915: Wait upon userptr get-user-pages within execbuffer
5e3982e drm/i915: First try the previous execbuffer location
2f93e2f drm/i915: Eliminate lots of iterations over the execobjects array
155a5c7 drm/i915: Pass vma to relocate entry
acc9363 drm/i915: Store a direct lookup from object handle to vma
3e9677a drm/i915: Split vma exec_link/evict_link
5a5cfe5 drm/i915: Use vma->exec_entry as our double-entry placeholder
7ea3245 drm/i915: Amalgamate execbuffer parameter structures
d8a64d9 drm/i915: Reinstate reservation_object zapping for batch_pool objects
1dca75c drm/i915: Split execlist priority queue into rbtree + linked list
8f5c72c drm/i915: Don't mark an execlists context-switch when idle
66953d3 drm/i915/execlists: Pack the count into the low bits of the port.request
913f088 drm/i915: Only report a wakeup if the waiter was truly asleep
d153946e drm/i915: Switch the global i915.semaphores check to a local predicate
95ac420 drm/i915: Do not record a successful syncpoint for a dma-await
6c682a7 drm/i915: Confirm the request is still active before adding it to the 
await
74936ad drm/i915: Rename intel_timeline.sync_seqno[] to .global_sync[]
c629206 drm/i915: Squash repeated awaits on the same fence
c5d2fa8 drm/i915: Redefine ptr_pack_bits() and friends
27a74c5 drm/i915: Make ptr_unpack_bits() more function-like
b422df4 drm/i915: Lift timeline ordering to await_dma_fence
942f00e drm/i915: Mark up clflushes as belonging to an unordered timeline
2c0d12b drm/i915: Mark CPU cache as dirty on every transition for CPU writes
e008f0e drm/i915/selftests: Allocate inode/file dynamically

== Logs ==

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

[Intel-gfx] [PATCH 18/27] drm/i915: Use vma->exec_entry as our double-entry placeholder

[Chris Wilson]

This has the benefit of not requiring us to manipulate the
vma->exec_link list when tearing down the execbuffer, and is a
marginally cheaper test to detect the user error.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_evict.c  | 17 ++-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 77 --
 drivers/gpu/drm/i915/i915_vma.c|  1 -
 3 files changed, 44 insertions(+), 51 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c 
b/drivers/gpu/drm/i915/i915_gem_evict.c
index 51e365f70464..891247d79299 100644
--- a/drivers/gpu/drm/i915/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/i915_gem_evict.c
@@ -59,9 +59,6 @@ mark_free(struct drm_mm_scan *scan,
if (i915_vma_is_pinned(vma))
return false;
 
-   if (WARN_ON(!list_empty(&vma->exec_list)))
-   return false;
-
if (flags & PIN_NONFAULT && !list_empty(&vma->obj->userfault_link))
return false;
 
@@ -160,8 +157,6 @@ i915_gem_evict_something(struct i915_address_space *vm,
list_for_each_entry_safe(vma, next, &eviction_list, exec_list) {
ret = drm_mm_scan_remove_block(&scan, &vma->node);
BUG_ON(ret);
-
-   INIT_LIST_HEAD(&vma->exec_list);
}
 
/* Can we unpin some objects such as idle hw contents,
@@ -209,17 +204,12 @@ i915_gem_evict_something(struct i915_address_space *vm,
if (drm_mm_scan_remove_block(&scan, &vma->node))
__i915_vma_pin(vma);
else
-   list_del_init(&vma->exec_list);
+   list_del(&vma->exec_list);
}
 
/* Unbinding will emit any required flushes */
ret = 0;
-   while (!list_empty(&eviction_list)) {
-   vma = list_first_entry(&eviction_list,
-  struct i915_vma,
-  exec_list);
-
-   list_del_init(&vma->exec_list);
+   list_for_each_entry_safe(vma, next, &eviction_list, exec_list) {
__i915_vma_unpin(vma);
if (ret == 0)
ret = i915_vma_unbind(vma);
@@ -315,7 +305,7 @@ int i915_gem_evict_for_node(struct i915_address_space *vm,
}
 
/* Overlap of objects in the same batch? */
-   if (i915_vma_is_pinned(vma) || !list_empty(&vma->exec_list)) {
+   if (i915_vma_is_pinned(vma)) {
ret = -ENOSPC;
if (vma->exec_entry &&
vma->exec_entry->flags & EXEC_OBJECT_PINNED)
@@ -336,7 +326,6 @@ int i915_gem_evict_for_node(struct i915_address_space *vm,
}
 
list_for_each_entry_safe(vma, next, &eviction_list, exec_list) {
-   list_del_init(&vma->exec_list);
__i915_vma_unpin(vma);
if (ret == 0)
ret = i915_vma_unbind(vma);
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 32c9750f7249..6d616662ef67 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -109,13 +109,40 @@ eb_create(struct i915_execbuffer *eb)
eb->and = -eb->args->buffer_count;
}
 
-   INIT_LIST_HEAD(&eb->vmas);
return 0;
 }
 
+static inline void
+__eb_unreserve_vma(struct i915_vma *vma,
+  const struct drm_i915_gem_exec_object2 *entry)
+{
+   if (unlikely(entry->flags & __EXEC_OBJECT_HAS_FENCE))
+   i915_vma_unpin_fence(vma);
+
+   if (entry->flags & __EXEC_OBJECT_HAS_PIN)
+   __i915_vma_unpin(vma);
+}
+
+static void
+eb_unreserve_vma(struct i915_vma *vma)
+{
+   struct drm_i915_gem_exec_object2 *entry = vma->exec_entry;
+
+   __eb_unreserve_vma(vma, entry);
+   entry->flags &= ~(__EXEC_OBJECT_HAS_FENCE | __EXEC_OBJECT_HAS_PIN);
+}
+
 static void
 eb_reset(struct i915_execbuffer *eb)
 {
+   struct i915_vma *vma;
+
+   list_for_each_entry(vma, &eb->vmas, exec_list) {
+   eb_unreserve_vma(vma);
+   i915_vma_put(vma);
+   vma->exec_entry = NULL;
+   }
+
if (eb->and >= 0)
memset(eb->buckets, 0, (eb->and+1)*sizeof(struct hlist_head));
 }
@@ -147,6 +174,8 @@ eb_lookup_vmas(struct i915_execbuffer *eb)
struct list_head objects;
int i, ret;
 
+   INIT_LIST_HEAD(&eb->vmas);
+
INIT_LIST_HEAD(&objects);
spin_lock(&eb->file->table_lock);
/* Grab a reference to the object and release the lock so we can lookup
@@ -253,40 +282,23 @@ static struct i915_vma *eb_get_vma(struct i915_execbuffer 
*eb, unsigned long han
}
 }
 
-static void
-eb_unreserve_vma(struct i915_vma *vma)
-{
-   struct drm_i915_gem_exec_object2 *entry;
-
-   if (!drm_mm_node_allocated(&vma->node))
-   return;
-

[Intel-gfx] [PATCH 24/27] drm/i915: Wait upon userptr get-user-pages within execbuffer

[Chris Wilson]

This simply hides the EAGAIN caused by userptr when userspace causes
resource contention. However, it is quite beneficial with highly
contended userptr users as we avoid repeating the setup costs and
kernel-user context switches.

Signed-off-by: Chris Wilson 
Reviewed-by: Michał Winiarski 
---
 drivers/gpu/drm/i915/i915_drv.c|  1 +
 drivers/gpu/drm/i915/i915_drv.h| 10 +-
 drivers/gpu/drm/i915/i915_gem.c|  4 +++-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  3 +++
 drivers/gpu/drm/i915/i915_gem_userptr.c| 18 +++---
 5 files changed, 31 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index cc7393e65e99..6ce736514396 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -553,6 +553,7 @@ static void i915_gem_fini(struct drm_i915_private *dev_priv)
intel_uc_fini_hw(dev_priv);
i915_gem_cleanup_engines(dev_priv);
i915_gem_context_fini(dev_priv);
+   i915_gem_cleanup_userptr(dev_priv);
mutex_unlock(&dev_priv->drm.struct_mutex);
 
i915_gem_drain_freed_objects(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b0c4b9cb75c2..915f6d700cfe 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1514,6 +1514,13 @@ struct i915_gem_mm {
/** LRU list of objects with fence regs on them. */
struct list_head fence_list;
 
+   /**
+* Workqueue to fault in userptr pages, flushed by the execbuf
+* when required but otherwise left to userspace to try again
+* on EAGAIN.
+*/
+   struct workqueue_struct *userptr_wq;
+
u64 unordered_timeline;
 
/* the indicator for dispatch video commands on two BSD rings */
@@ -3208,7 +3215,8 @@ int i915_gem_set_tiling_ioctl(struct drm_device *dev, 
void *data,
  struct drm_file *file_priv);
 int i915_gem_get_tiling_ioctl(struct drm_device *dev, void *data,
  struct drm_file *file_priv);
-void i915_gem_init_userptr(struct drm_i915_private *dev_priv);
+int i915_gem_init_userptr(struct drm_i915_private *dev_priv);
+void i915_gem_cleanup_userptr(struct drm_i915_private *dev_priv);
 int i915_gem_userptr_ioctl(struct drm_device *dev, void *data,
   struct drm_file *file);
 int i915_gem_get_aperture_ioctl(struct drm_device *dev, void *data,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index ed761a122966..55cb8a2cb99b 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4791,7 +4791,9 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
 */
intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
 
-   i915_gem_init_userptr(dev_priv);
+   ret = i915_gem_init_userptr(dev_priv);
+   if (ret)
+   goto out_unlock;
 
ret = i915_gem_init_ggtt(dev_priv);
if (ret)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index f4b5e221708d..44413594ba47 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1473,6 +1473,9 @@ static int eb_relocate_slow(struct i915_execbuffer *eb)
goto out;
}
 
+   /* A frequent cause for EAGAIN are currently unavailable client pages */
+   flush_workqueue(eb->i915->mm.userptr_wq);
+
err = i915_mutex_lock_interruptible(dev);
if (err) {
mutex_lock(&dev->struct_mutex);
diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c 
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 9f84be171ad2..8b5232688de0 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -378,7 +378,7 @@ __i915_mm_struct_free(struct kref *kref)
mutex_unlock(&mm->i915->mm_lock);
 
INIT_WORK(&mm->work, __i915_mm_struct_free__worker);
-   schedule_work(&mm->work);
+   queue_work(mm->i915->mm.userptr_wq, &mm->work);
 }
 
 static void
@@ -598,7 +598,7 @@ __i915_gem_userptr_get_pages_schedule(struct 
drm_i915_gem_object *obj)
get_task_struct(work->task);
 
INIT_WORK(&work->work, __i915_gem_userptr_get_pages_worker);
-   schedule_work(&work->work);
+   queue_work(to_i915(obj->base.dev)->mm.userptr_wq, &work->work);
 
return ERR_PTR(-EAGAIN);
 }
@@ -829,8 +829,20 @@ i915_gem_userptr_ioctl(struct drm_device *dev, void *data, 
struct drm_file *file
return 0;
 }
 
-void i915_gem_init_userptr(struct drm_i915_private *dev_priv)
+int i915_gem_init_userptr(struct drm_i915_private *dev_priv)
 {
mutex_init(&dev_priv->mm_lock);
hash_init(dev_priv->mm_structs);
+
+   dev_priv->mm.userptr_wq =
+   alloc_workqueue("i915-userptr-acquire", WQ_HIGHPRI, 0);
+   if (!dev_priv->mm.userptr_wq)
+   

[Intel-gfx] [PATCH 23/27] drm/i915: First try the previous execbuffer location

[Chris Wilson]

When choosing a slot for an execbuffer, we ideally want to use the same
address as last time (so that we don't have to rebind it) and the same
address as expected by the user (so that we don't have to fixup any
relocations pointing to it). If we first try to bind the incoming
execbuffer->offset from the user, or the currently bound offset that
should hopefully achieve the goal of avoiding the rebind cost and the
relocation penalty. However, if the object is not currently bound there
we don't want to arbitrarily unbind an object in our chosen position and
so choose to rebind/relocate the incoming object instead. After we
report the new position back to the user, on the next pass the
relocations should have settled down.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 12 
 drivers/gpu/drm/i915/i915_gem_gtt.c|  6 ++
 drivers/gpu/drm/i915/i915_gem_gtt.h|  1 +
 3 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index de41e423d3f7..f4b5e221708d 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -329,10 +329,15 @@ eb_pin_vma(struct i915_execbuffer *eb,
 {
u64 flags;
 
-   flags = vma->node.start;
-   flags |= PIN_USER | PIN_NONBLOCK | PIN_OFFSET_FIXED;
+   if (vma->node.size)
+   flags = vma->node.start;
+   else
+   flags = entry->offset & PIN_OFFSET_MASK;
+
+   flags |= PIN_USER | PIN_NOEVICT | PIN_OFFSET_FIXED;
if (unlikely(entry->flags & EXEC_OBJECT_NEEDS_GTT))
flags |= PIN_GLOBAL;
+
if (unlikely(i915_vma_pin(vma, 0, 0, flags)))
return;
 
@@ -460,8 +465,7 @@ eb_add_vma(struct i915_execbuffer *eb,
entry->flags |= eb->context_flags;
 
err = 0;
-   if (vma->node.size)
-   eb_pin_vma(eb, entry, vma);
+   eb_pin_vma(eb, entry, vma);
if (eb_vma_misplaced(entry, vma)) {
eb_unreserve_vma(vma, entry);
 
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 8bab4aea63e6..62871cd50605 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3288,6 +3288,9 @@ int i915_gem_gtt_reserve(struct i915_address_space *vm,
if (err != -ENOSPC)
return err;
 
+   if (flags & PIN_NOEVICT)
+   return -ENOSPC;
+
err = i915_gem_evict_for_node(vm, node, flags);
if (err == 0)
err = drm_mm_reserve_node(&vm->mm, node);
@@ -3402,6 +3405,9 @@ int i915_gem_gtt_insert(struct i915_address_space *vm,
if (err != -ENOSPC)
return err;
 
+   if (flags & PIN_NOEVICT)
+   return -ENOSPC;
+
/* No free space, pick a slot at random.
 *
 * There is a pathological case here using a GTT shared between
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h 
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index fb15684c1d83..a528ce1380fd 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -588,6 +588,7 @@ int i915_gem_gtt_insert(struct i915_address_space *vm,
 #define PIN_MAPPABLE   BIT(1)
 #define PIN_ZONE_4GBIT(2)
 #define PIN_NONFAULT   BIT(3)
+#define PIN_NOEVICTBIT(4)
 
 #define PIN_MBZBIT(5) /* I915_VMA_PIN_OVERFLOW */
 #define PIN_GLOBAL BIT(6) /* I915_VMA_GLOBAL_BIND */
-- 
2.11.0

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

[Intel-gfx] [PATCH 17/27] drm/i915: Amalgamate execbuffer parameter structures

[Chris Wilson]

Combine the two slightly overlapping parameter structures we pass around
the execbuffer routines into one.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 550 -
 1 file changed, 233 insertions(+), 317 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index ddc011ef5480..32c9750f7249 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -50,70 +50,78 @@
 
 #define BATCH_OFFSET_BIAS (256*1024)
 
-struct i915_execbuffer_params {
-   struct drm_device   *dev;
-   struct drm_file *file;
-   struct i915_vma *batch;
-   u32 dispatch_flags;
-   u32 args_batch_start_offset;
-   struct intel_engine_cs  *engine;
-   struct i915_gem_context *ctx;
-   struct drm_i915_gem_request *request;
-};
+#define __I915_EXEC_ILLEGAL_FLAGS \
+   (__I915_EXEC_UNKNOWN_FLAGS | I915_EXEC_CONSTANTS_MASK)
 
-struct eb_vmas {
+struct i915_execbuffer {
struct drm_i915_private *i915;
+   struct drm_file *file;
+   struct drm_i915_gem_execbuffer2 *args;
+   struct drm_i915_gem_exec_object2 *exec;
+   struct intel_engine_cs *engine;
+   struct i915_gem_context *ctx;
+   struct i915_address_space *vm;
+   struct i915_vma *batch;
+   struct drm_i915_gem_request *request;
+   u32 batch_start_offset;
+   u32 batch_len;
+   unsigned int dispatch_flags;
+   struct drm_i915_gem_exec_object2 shadow_exec_entry;
+   bool need_relocs;
struct list_head vmas;
+   struct reloc_cache {
+   struct drm_mm_node node;
+   unsigned long vaddr;
+   unsigned int page;
+   bool use_64bit_reloc : 1;
+   } reloc_cache;
int and;
union {
-   struct i915_vma *lut[0];
-   struct hlist_head buckets[0];
+   struct i915_vma **lut;
+   struct hlist_head *buckets;
};
 };
 
-static struct eb_vmas *
-eb_create(struct drm_i915_private *i915,
- struct drm_i915_gem_execbuffer2 *args)
+static int
+eb_create(struct i915_execbuffer *eb)
 {
-   struct eb_vmas *eb = NULL;
-
-   if (args->flags & I915_EXEC_HANDLE_LUT) {
-   unsigned size = args->buffer_count;
+   eb->lut = NULL;
+   if (eb->args->flags & I915_EXEC_HANDLE_LUT) {
+   unsigned int size = eb->args->buffer_count;
size *= sizeof(struct i915_vma *);
-   size += sizeof(struct eb_vmas);
-   eb = kmalloc(size, GFP_TEMPORARY | __GFP_NOWARN | 
__GFP_NORETRY);
+   eb->lut = kmalloc(size,
+ GFP_TEMPORARY | __GFP_NOWARN | __GFP_NORETRY);
}
 
-   if (eb == NULL) {
-   unsigned size = args->buffer_count;
-   unsigned count = PAGE_SIZE / sizeof(struct hlist_head) / 2;
+   if (!eb->lut) {
+   unsigned int size = eb->args->buffer_count;
+   unsigned int count = PAGE_SIZE / sizeof(struct hlist_head) / 2;
BUILD_BUG_ON_NOT_POWER_OF_2(PAGE_SIZE / sizeof(struct 
hlist_head));
while (count > 2*size)
count >>= 1;
-   eb = kzalloc(count*sizeof(struct hlist_head) +
-sizeof(struct eb_vmas),
-GFP_TEMPORARY);
-   if (eb == NULL)
-   return eb;
+   eb->lut = kzalloc(count*sizeof(struct hlist_head),
+ GFP_TEMPORARY);
+   if (!eb->lut)
+   return -ENOMEM;
 
eb->and = count - 1;
-   } else
-   eb->and = -args->buffer_count;
+   } else {
+   eb->and = -eb->args->buffer_count;
+   }
 
-   eb->i915 = i915;
INIT_LIST_HEAD(&eb->vmas);
-   return eb;
+   return 0;
 }
 
 static void
-eb_reset(struct eb_vmas *eb)
+eb_reset(struct i915_execbuffer *eb)
 {
if (eb->and >= 0)
memset(eb->buckets, 0, (eb->and+1)*sizeof(struct hlist_head));
 }
 
 static struct i915_vma *
-eb_get_batch(struct eb_vmas *eb)
+eb_get_batch(struct i915_execbuffer *eb)
 {
struct i915_vma *vma = list_entry(eb->vmas.prev, typeof(*vma), 
exec_list);
 
@@ -133,34 +141,30 @@ eb_get_batch(struct eb_vmas *eb)
 }
 
 static int
-eb_lookup_vmas(struct eb_vmas *eb,
-  struct drm_i915_gem_exec_object2 *exec,
-  const struct drm_i915_gem_execbuffer2 *args,
-  struct i915_address_space *vm,
-  struct drm_file *file)
+eb_lookup_vmas(struct i915_execbuffer *eb)
 {
struct drm_i915_gem_object *obj;
struct list_head objects;
int i, ret;
 
INIT_LIST_HEAD(&objects

[Intel-gfx] [PATCH 19/27] drm/i915: Split vma exec_link/evict_link

[Chris Wilson]

Currently the vma has one link member that is used for both holding its
place in the execbuf reservation list, and in any eviction list. This
dual property is quite tricky and error prone.

Signed-off-by: Chris Wilson 
Reviewed-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem_evict.c  | 14 ++---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 32 +++---
 drivers/gpu/drm/i915/i915_vma.h|  7 +--
 3 files changed, 28 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c 
b/drivers/gpu/drm/i915/i915_gem_evict.c
index 891247d79299..204a2d9288ae 100644
--- a/drivers/gpu/drm/i915/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/i915_gem_evict.c
@@ -62,7 +62,7 @@ mark_free(struct drm_mm_scan *scan,
if (flags & PIN_NONFAULT && !list_empty(&vma->obj->userfault_link))
return false;
 
-   list_add(&vma->exec_list, unwind);
+   list_add(&vma->evict_link, unwind);
return drm_mm_scan_add_block(scan, &vma->node);
 }
 
@@ -154,7 +154,7 @@ i915_gem_evict_something(struct i915_address_space *vm,
} while (*++phase);
 
/* Nothing found, clean up and bail out! */
-   list_for_each_entry_safe(vma, next, &eviction_list, exec_list) {
+   list_for_each_entry_safe(vma, next, &eviction_list, evict_link) {
ret = drm_mm_scan_remove_block(&scan, &vma->node);
BUG_ON(ret);
}
@@ -200,16 +200,16 @@ i915_gem_evict_something(struct i915_address_space *vm,
 * calling unbind (which may remove the active reference
 * of any of our objects, thus corrupting the list).
 */
-   list_for_each_entry_safe(vma, next, &eviction_list, exec_list) {
+   list_for_each_entry_safe(vma, next, &eviction_list, evict_link) {
if (drm_mm_scan_remove_block(&scan, &vma->node))
__i915_vma_pin(vma);
else
-   list_del(&vma->exec_list);
+   list_del(&vma->evict_link);
}
 
/* Unbinding will emit any required flushes */
ret = 0;
-   list_for_each_entry_safe(vma, next, &eviction_list, exec_list) {
+   list_for_each_entry_safe(vma, next, &eviction_list, evict_link) {
__i915_vma_unpin(vma);
if (ret == 0)
ret = i915_vma_unbind(vma);
@@ -322,10 +322,10 @@ int i915_gem_evict_for_node(struct i915_address_space *vm,
 * reference) another in our eviction list.
 */
__i915_vma_pin(vma);
-   list_add(&vma->exec_list, &eviction_list);
+   list_add(&vma->evict_link, &eviction_list);
}
 
-   list_for_each_entry_safe(vma, next, &eviction_list, exec_list) {
+   list_for_each_entry_safe(vma, next, &eviction_list, evict_link) {
__i915_vma_unpin(vma);
if (ret == 0)
ret = i915_vma_unbind(vma);
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 6d616662ef67..42468cbf7678 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -137,7 +137,7 @@ eb_reset(struct i915_execbuffer *eb)
 {
struct i915_vma *vma;
 
-   list_for_each_entry(vma, &eb->vmas, exec_list) {
+   list_for_each_entry(vma, &eb->vmas, exec_link) {
eb_unreserve_vma(vma);
i915_vma_put(vma);
vma->exec_entry = NULL;
@@ -150,7 +150,7 @@ eb_reset(struct i915_execbuffer *eb)
 static struct i915_vma *
 eb_get_batch(struct i915_execbuffer *eb)
 {
-   struct i915_vma *vma = list_entry(eb->vmas.prev, typeof(*vma), 
exec_list);
+   struct i915_vma *vma = list_entry(eb->vmas.prev, typeof(*vma), 
exec_link);
 
/*
 * SNA is doing fancy tricks with compressing batch buffers, which leads
@@ -227,7 +227,7 @@ eb_lookup_vmas(struct i915_execbuffer *eb)
}
 
/* Transfer ownership from the objects list to the vmas list. */
-   list_add_tail(&vma->exec_list, &eb->vmas);
+   list_add_tail(&vma->exec_link, &eb->vmas);
list_del_init(&obj->obj_exec_link);
 
vma->exec_entry = &eb->exec[i];
@@ -286,7 +286,7 @@ static void eb_destroy(struct i915_execbuffer *eb)
 {
struct i915_vma *vma;
 
-   list_for_each_entry(vma, &eb->vmas, exec_list) {
+   list_for_each_entry(vma, &eb->vmas, exec_link) {
if (!vma->exec_entry)
continue;
 
@@ -752,7 +752,7 @@ static int eb_relocate(struct i915_execbuffer *eb)
struct i915_vma *vma;
int ret = 0;
 
-   list_for_each_entry(vma, &eb->vmas, exec_list) {
+   list_for_each_entry(vma, &eb->vmas, exec_link) {
ret = eb_relocate_vma(vma, eb);
if (ret)
break;
@@ -905,7 +905,7 @@ static int eb_rese

[Intel-gfx] [PATCH 26/27] drm/i915: Async GPU relocation processing

[Chris Wilson]

If the user requires patching of their batch or auxiliary buffers, we
currently make the alterations on the cpu. If they are active on the GPU
at the time, we wait under the struct_mutex for them to finish executing
before we rewrite the contents. This happens if shared relocation trees
are used between different contexts with separate address space (and the
buffers then have different addresses in each), the 3D state will need
to be adjusted between execution on each context. However, we don't need
to use the CPU to do the relocation patching, as we could queue commands
to the GPU to perform it and use fences to serialise the operation with
the current activity and future - so the operation on the GPU appears
just as atomic as performing it immediately. Performing the relocation
rewrites on the GPU is not free, in terms of pure throughput, the number
of relocations/s is about halved - but more importantly so is the time
under the struct_mutex.

v2: Break out the request/batch allocation for clearer error flow.
v3: A few asserts to ensure rq ordering is maintained

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem.c|   1 -
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 225 -
 2 files changed, 219 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 55cb8a2cb99b..7d9cabdab89a 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4381,7 +4381,6 @@ static void __i915_gem_free_objects(struct 
drm_i915_private *i915,
GEM_BUG_ON(i915_gem_object_is_active(obj));
list_for_each_entry_safe(vma, vn,
 &obj->vma_list, obj_link) {
-   GEM_BUG_ON(!i915_vma_is_ggtt(vma));
GEM_BUG_ON(i915_vma_is_active(vma));
vma->flags &= ~I915_VMA_PIN_MASK;
i915_vma_close(vma);
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 1da7c3a46436..e35476b0ca1b 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -40,7 +40,12 @@
 #include "intel_drv.h"
 #include "intel_frontbuffer.h"
 
-#define DBG_USE_CPU_RELOC 0 /* -1 force GTT relocs; 1 force CPU relocs */
+enum {
+   FORCE_CPU_RELOC = 1,
+   FORCE_GTT_RELOC,
+   FORCE_GPU_RELOC,
+#define DBG_FORCE_RELOC 0 /* choose one of the above! */
+};
 
 #define  __EXEC_OBJECT_HAS_PIN BIT(31)
 #define  __EXEC_OBJECT_HAS_FENCE   BIT(30)
@@ -210,10 +215,15 @@ struct i915_execbuffer {
struct drm_mm_node node; /** temporary GTT binding */
unsigned long vaddr; /** Current kmap address */
unsigned long page; /** Currently mapped page index */
+   unsigned int gen; /** Cached value of INTEL_GEN */
bool use_64bit_reloc : 1;
bool has_llc : 1;
bool has_fence : 1;
bool needs_unfenced : 1;
+
+   struct drm_i915_gem_request *rq;
+   u32 *rq_cmd;
+   unsigned int rq_size;
} reloc_cache;
 
u64 invalid_flags; /** Set of execobj.flags that are invalid */
@@ -487,8 +497,11 @@ static inline int use_cpu_reloc(const struct reloc_cache 
*cache,
if (!i915_gem_object_has_struct_page(obj))
return false;
 
-   if (DBG_USE_CPU_RELOC)
-   return DBG_USE_CPU_RELOC > 0;
+   if (DBG_FORCE_RELOC == FORCE_CPU_RELOC)
+   return true;
+
+   if (DBG_FORCE_RELOC == FORCE_GTT_RELOC)
+   return false;
 
return (cache->has_llc ||
obj->cache_dirty ||
@@ -864,6 +877,8 @@ static void eb_release_vma(const struct i915_execbuffer *eb)
 
 static void eb_destroy(const struct i915_execbuffer *eb)
 {
+   GEM_BUG_ON(eb->reloc_cache.rq);
+
if (eb->lut_size >= 0)
kfree(eb->buckets);
 }
@@ -881,11 +896,14 @@ static void reloc_cache_init(struct reloc_cache *cache,
cache->page = -1;
cache->vaddr = 0;
/* Must be a variable in the struct to allow GCC to unroll. */
+   cache->gen = INTEL_GEN(i915);
cache->has_llc = HAS_LLC(i915);
-   cache->has_fence = INTEL_GEN(i915) < 4;
-   cache->needs_unfenced = INTEL_INFO(i915)->unfenced_needs_alignment;
cache->use_64bit_reloc = HAS_64BIT_RELOC(i915);
+   cache->has_fence = cache->gen < 4;
+   cache->needs_unfenced = INTEL_INFO(i915)->unfenced_needs_alignment;
cache->node.allocated = false;
+   cache->rq = NULL;
+   cache->rq_size = 0;
 }
 
 static inline void *unmask_page(unsigned long p)
@@ -907,10 +925,24 @@ static inline struct i915_ggtt *cache_to_ggtt(struct 
reloc_cache *cache)
return &i915->ggtt;
 }
 
+static void reloc_gpu_flush(struct reloc_cache *cache)
+{
+   

[Intel-gfx] [PATCH 25/27] drm/i915: Allow execbuffer to use the first object as the batch

[Chris Wilson]

Currently, the last object in the execlist is the always the batch.
However, when building the batch buffer we often know the batch object
first and if we can use the first slot in the execlist we can emit
relocation instructions relative to it immediately and avoid a separate
pass to adjust the relocations to point to the last execlist slot.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_drv.c|  1 +
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  5 -
 include/uapi/drm/i915_drm.h| 16 +++-
 3 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 6ce736514396..5f2aeb27aeb7 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -351,6 +351,7 @@ static int i915_getparam(struct drm_device *dev, void *data,
case I915_PARAM_HAS_EXEC_ASYNC:
case I915_PARAM_HAS_EXEC_FENCE:
case I915_PARAM_HAS_EXEC_CAPTURE:
+   case I915_PARAM_HAS_EXEC_BATCH_FIRST:
/* For the time being all of these are always true;
 * if some supported hardware does not have one of these
 * features this value needs to be provided from
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 44413594ba47..1da7c3a46436 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -622,7 +622,10 @@ ht_needs_resize(const struct i915_gem_context_vma_lut *lut)
 
 static unsigned int eb_batch_index(const struct i915_execbuffer *eb)
 {
-   return eb->buffer_count - 1;
+   if (eb->args->flags & I915_EXEC_BATCH_FIRST)
+   return 0;
+   else
+   return eb->buffer_count - 1;
 }
 
 static int eb_select_context(struct i915_execbuffer *eb)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index f24a80d2d42e..f43a22ae955b 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -418,6 +418,11 @@ typedef struct drm_i915_irq_wait {
  */
 #define I915_PARAM_HAS_EXEC_CAPTURE 45
 
+/* Query whether DRM_I915_GEM_EXECBUFFER2 supports supplying the batch buffer
+ * as the first execobject as opposed to the last. See I915_EXEC_BATCH_FIRST.
+ */
+#define I915_PARAM_HAS_EXEC_BATCH_FIRST 46
+
 typedef struct drm_i915_getparam {
__s32 param;
/*
@@ -904,7 +909,16 @@ struct drm_i915_gem_execbuffer2 {
  */
 #define I915_EXEC_FENCE_OUT(1<<17)
 
-#define __I915_EXEC_UNKNOWN_FLAGS (-(I915_EXEC_FENCE_OUT<<1))
+/* Traditionally the execbuf ioctl has only considered the final element in
+ * the execobject[] to be the executable batch. Often though, the client
+ * will known the batch object prior to construction and being able to place
+ * it into the execobject[] array first can simplify the relocation tracking.
+ * Setting I915_EXEC_BATCH_FIRST tells execbuf to use element 0 of the
+ * execobject[] as the * batch instead (the default is to use the last
+ * element).
+ */
+#define I915_EXEC_BATCH_FIRST  (1<<18)
+#define __I915_EXEC_UNKNOWN_FLAGS (-(I915_EXEC_BATCH_FIRST<<1))
 
 #define I915_EXEC_CONTEXT_ID_MASK  (0x)
 #define i915_execbuffer2_set_context_id(eb2, context) \
-- 
2.11.0

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

[Intel-gfx] [PATCH 27/27] drm/i915/scheduler: Support user-defined priorities

[Chris Wilson]

Use a priority stored in the context as the initial value when
submitting a request. This allows us to change the default priority on a
per-context basis, allowing different contexts to be favoured with GPU
time at the expense of lower importance work. The user can adjust the
context's priority via I915_CONTEXT_PARAM_PRIORITY, with more positive
values being higher priority (they will be serviced earlier, after their
dependencies have been resolved). Any prerequisite work for an execbuf
will have its priority raised to match the new request as required.

Normal users can specify any value in the range of -1023 to 0 [default],
i.e. they can reduce the priority of their workloads (and temporarily
boost it back to normal if so desired).

Privileged users can specify any value in the range of -1023 to 1023,
[default is 0], i.e. they can raise their priority above all overs and
so potentially starve the system.

Note that the existing schedulers are not fair, nor load balancing, the
execution is strictly by priority on a first-come, first-served basis,
and the driver may choose to boost some requests above the range
available to users.

This priority was originally based around nice(2), but evolved to allow
clients to adjust their priority within a small range, and allow for a
privileged high priority range.

For example, this can be used to implement EGL_IMG_context_priority
https://www.khronos.org/registry/egl/extensions/IMG/EGL_IMG_context_priority.txt

EGL_CONTEXT_PRIORITY_LEVEL_IMG determines the priority level of
the context to be created. This attribute is a hint, as an
implementation may not support multiple contexts at some
priority levels and system policy may limit access to high
priority contexts to appropriate system privilege level. The
default value for EGL_CONTEXT_PRIORITY_LEVEL_IMG is
EGL_CONTEXT_PRIORITY_MEDIUM_IMG."

so we can map

PRIORITY_HIGH -> 1023 [privileged, will failback to 0]
PRIORITY_MED -> 0 [default]
PRIORITY_LOW -> -1023

They also map onto the priorities used by VkQueue (and a VkQueue is
essentially a timeline, our i915_gem_context under full-ppgtt).

v2: s/CAP_SYS_ADMIN/CAP_SYS_NICE/

Testcase: igt/gem_exec_schedule
Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem_context.c | 22 ++
 include/uapi/drm/i915_drm.h |  3 +++
 2 files changed, 25 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 23fd1470a7f4..694eddba51a6 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -1141,6 +1141,9 @@ int i915_gem_context_getparam_ioctl(struct drm_device 
*dev, void *data,
case I915_CONTEXT_PARAM_BANNABLE:
args->value = i915_gem_context_is_bannable(ctx);
break;
+   case I915_CONTEXT_PARAM_PRIORITY:
+   args->value = ctx->priority;
+   break;
default:
ret = -EINVAL;
break;
@@ -1198,6 +1201,25 @@ int i915_gem_context_setparam_ioctl(struct drm_device 
*dev, void *data,
else
i915_gem_context_clear_bannable(ctx);
break;
+
+   case I915_CONTEXT_PARAM_PRIORITY:
+   {
+   int priority = args->value;
+
+   if (args->size)
+   ret = -EINVAL;
+   else if (!to_i915(dev)->engine[RCS]->schedule)
+   ret = -ENODEV;
+   else if (priority >= I915_PRIORITY_MAX ||
+priority <= I915_PRIORITY_MIN)
+   ret = -EINVAL;
+   else if (priority > 0 && !capable(CAP_SYS_NICE))
+   ret = -EPERM;
+   else
+   ctx->priority = priority;
+   }
+   break;
+
default:
ret = -EINVAL;
break;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index f43a22ae955b..200f2cf393b2 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -395,6 +395,8 @@ typedef struct drm_i915_irq_wait {
 
 /* Query whether DRM_I915_GEM_EXECBUFFER2 supports user defined execution
  * priorities and the driver will attempt to execute batches in priority order.
+ * The initial priority for each batch is supplied by the context and is
+ * controlled via I915_CONTEXT_PARAM_PRIORITY.
  */
 #define I915_PARAM_HAS_SCHEDULER41
 #define I915_PARAM_HUC_STATUS   42
@@ -1318,6 +1320,7 @@ struct drm_i915_gem_context_param {
 #define I915_CONTEXT_PARAM_GTT_SIZE0x3
 #define I915_CONTEXT_PARAM_NO_ERROR_CAPTURE0x4
 #define I915_CONTEXT_PARAM_BANNABLE0x5
+#define I915_CONTEXT_PARAM_PRIORITY0x6
__u64 v

[Intel-gfx] [PATCH 11/27] drm/i915: Switch the global i915.semaphores check to a local predicate

[Chris Wilson]

Rather than use a global modparam, we can just check to see if the
engine has semaphores configured upon it.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_request.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 75b33993468f..83b1584b3deb 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -703,10 +703,12 @@ i915_gem_request_await_request(struct 
drm_i915_gem_request *to,
if (!seqno)
goto await_dma_fence;
 
-   if (!i915.semaphores) {
+   if (!to->engine->semaphore.sync_to) {
if (!__i915_spin_request(from, seqno, TASK_INTERRUPTIBLE, 2))
goto await_dma_fence;
} else {
+   GEM_BUG_ON(!from->engine->semaphore.signal);
+
if (seqno <= to->timeline->global_sync[from->engine->id])
return 0;
 
-- 
2.11.0

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

[Intel-gfx] [PATCH 20/27] drm/i915: Store a direct lookup from object handle to vma

[Chris Wilson]

The advent of full-ppgtt lead to an extra indirection between the object
and its binding. That extra indirection has a noticeable impact on how
fast we can convert from the user handles to our internal vma for
execbuffer. In order to bypass the extra indirection, we use a
resizable hashtable to jump from the object to the per-ctx vma.
rhashtable was considered but we don't need the online resizing feature
and the extra complexity proved to undermine its usefulness. Instead, we
simply reallocate the hastable on demand in a background task and
serialize it before iterating.

In non-full-ppgtt modes, multiple files and multiple contexts can share
the same vma. This leads to having multiple possible handle->vma links,
so we only use the first to establish the fast path. The majority of
buffers are not shared and so we should still be able to realise
speedups with multiple clients.

v2: Prettier names, more magic.
v3: Many style tweaks, most notably hiding the misuse of execobj[].rsvd2

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_debugfs.c   |   6 +
 drivers/gpu/drm/i915/i915_drv.h   |   2 +-
 drivers/gpu/drm/i915/i915_gem.c   |   5 +-
 drivers/gpu/drm/i915/i915_gem_context.c   |  86 -
 drivers/gpu/drm/i915/i915_gem_context.h   |  25 +++
 drivers/gpu/drm/i915/i915_gem_execbuffer.c| 261 --
 drivers/gpu/drm/i915/i915_gem_object.h|   4 +-
 drivers/gpu/drm/i915/i915_utils.h |   5 +
 drivers/gpu/drm/i915/i915_vma.c   |  20 ++
 drivers/gpu/drm/i915/i915_vma.h   |   8 +-
 drivers/gpu/drm/i915/selftests/mock_context.c |  12 +-
 11 files changed, 320 insertions(+), 114 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index a8c7788d986e..a2472048b84d 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1988,6 +1988,12 @@ static int i915_context_status(struct seq_file *m, void 
*unused)
seq_putc(m, '\n');
}
 
+   seq_printf(m,
+  "\tvma hashtable size=%u (actual %lu), count=%u\n",
+  ctx->vma_lut.ht_size,
+  BIT(ctx->vma_lut.ht_bits),
+  ctx->vma_lut.ht_count);
+
seq_putc(m, '\n');
}
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a11d7d8f5f2e..7b6926861e04 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -37,7 +37,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index f6df402a5247..ed761a122966 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3247,6 +3247,10 @@ void i915_gem_close_object(struct drm_gem_object *gem, 
struct drm_file *file)
if (vma->vm->file == fpriv)
i915_vma_close(vma);
 
+   vma = obj->vma_hashed;
+   if (vma && vma->ctx->file_priv == fpriv)
+   i915_vma_unlink_ctx(vma);
+
if (i915_gem_object_is_active(obj) &&
!i915_gem_object_has_active_reference(obj)) {
i915_gem_object_set_active_reference(obj);
@@ -4240,7 +4244,6 @@ void i915_gem_object_init(struct drm_i915_gem_object *obj,
 
INIT_LIST_HEAD(&obj->global_link);
INIT_LIST_HEAD(&obj->userfault_link);
-   INIT_LIST_HEAD(&obj->obj_exec_link);
INIT_LIST_HEAD(&obj->vma_list);
INIT_LIST_HEAD(&obj->batch_pool_link);
 
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 8bd0c4966913..23fd1470a7f4 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -85,6 +85,7 @@
  *
  */
 
+#include 
 #include 
 #include 
 #include "i915_drv.h"
@@ -92,6 +93,9 @@
 
 #define ALL_L3_SLICES(dev) (1 << NUM_L3_SLICES(dev)) - 1
 
+/* Initial size (as log2) to preallocate the handle->object hashtable */
+#define VMA_HT_BITS 2u /* 4 x 2 pointers, 64 bytes minimum */
+
 static int get_context_size(struct drm_i915_private *dev_priv)
 {
int ret;
@@ -119,6 +123,67 @@ static int get_context_size(struct drm_i915_private 
*dev_priv)
return ret;
 }
 
+static void resize_vma_ht(struct work_struct *work)
+{
+   struct i915_gem_context_vma_lut *lut =
+   container_of(work, typeof(*lut), resize);
+   unsigned int bits, new_bits, size, i;
+   struct hlist_head *new_ht;
+
+   GEM_BUG_ON(!(lut->ht_size & I915_CTX_RESIZE_IN_PROGRESS));
+
+   bits = 1 + ilog2(4*lut->ht_count/3 + 1);
+   new_bits = min_t(unsigned int,
+max(bits, VMA_HT_BITS),
+sizeof(unsigned int) * BITS_PER_BYTE - 1);
+   if (new_bits == lut->ht_bit

[Intel-gfx] [PATCH 21/27] drm/i915: Pass vma to relocate entry

[Chris Wilson]

We can simplify our tracking of pending writes in an execbuf to the
single bit in the vma->exec_entry->flags, but that requires the
relocation function knowing the object's vma. Pass it along.

Note we have only been using a single bit to track flushing since

commit cc889e0f6ce6a63c62db17d702ecfed86d58083f
Author: Daniel Vetter 
Date:   Wed Jun 13 20:45:19 2012 +0200

drm/i915: disable flushing_list/gpu_write_list

unconditionally flushed all render caches before the breadcrumb and

commit 6ac42f4148bc27e5ffd18a9ab0eac57f58822af4
Author: Daniel Vetter 
Date:   Sat Jul 21 12:25:01 2012 +0200

drm/i915: Replace the complex flushing logic with simple invalidate/flush 
all

did away with the explicit GPU domain tracking. This was then codified
into the ABI with NO_RELOC in

commit ed5982e6ce5f106abcbf071f80730db344a6da42
Author: Daniel Vetter  # Oi! Patch stealer!
Date:   Thu Jan 17 22:23:36 2013 +0100

drm/i915: Allow userspace to hint that the relocations were known

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 101 -
 1 file changed, 41 insertions(+), 60 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 3684446df6b6..f166dae7ef28 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -620,42 +620,25 @@ relocate_entry(struct drm_i915_gem_object *obj,
 }
 
 static int
-eb_relocate_entry(struct drm_i915_gem_object *obj,
+eb_relocate_entry(struct i915_vma *vma,
  struct i915_execbuffer *eb,
  struct drm_i915_gem_relocation_entry *reloc)
 {
-   struct drm_gem_object *target_obj;
-   struct drm_i915_gem_object *target_i915_obj;
-   struct i915_vma *target_vma;
-   uint64_t target_offset;
+   struct i915_vma *target;
+   u64 target_offset;
int ret;
 
/* we've already hold a reference to all valid objects */
-   target_vma = eb_get_vma(eb, reloc->target_handle);
-   if (unlikely(target_vma == NULL))
+   target = eb_get_vma(eb, reloc->target_handle);
+   if (unlikely(!target))
return -ENOENT;
-   target_i915_obj = target_vma->obj;
-   target_obj = &target_vma->obj->base;
-
-   target_offset = gen8_canonical_addr(target_vma->node.start);
-
-   /* Sandybridge PPGTT errata: We need a global gtt mapping for MI and
-* pipe_control writes because the gpu doesn't properly redirect them
-* through the ppgtt for non_secure batchbuffers. */
-   if (unlikely(IS_GEN6(eb->i915) &&
-reloc->write_domain == I915_GEM_DOMAIN_INSTRUCTION)) {
-   ret = i915_vma_bind(target_vma, target_i915_obj->cache_level,
-   PIN_GLOBAL);
-   if (WARN_ONCE(ret, "Unexpected failure to bind target VMA!"))
-   return ret;
-   }
 
/* Validate that the target is in a valid r/w GPU domain */
if (unlikely(reloc->write_domain & (reloc->write_domain - 1))) {
DRM_DEBUG("reloc with multiple write domains: "
- "obj %p target %d offset %d "
+ "target %d offset %d "
  "read %08x write %08x",
- obj, reloc->target_handle,
+ reloc->target_handle,
  (int) reloc->offset,
  reloc->read_domains,
  reloc->write_domain);
@@ -664,43 +647,56 @@ eb_relocate_entry(struct drm_i915_gem_object *obj,
if (unlikely((reloc->write_domain | reloc->read_domains)
 & ~I915_GEM_GPU_DOMAINS)) {
DRM_DEBUG("reloc with read/write non-GPU domains: "
- "obj %p target %d offset %d "
+ "target %d offset %d "
  "read %08x write %08x",
- obj, reloc->target_handle,
+ reloc->target_handle,
  (int) reloc->offset,
  reloc->read_domains,
  reloc->write_domain);
return -EINVAL;
}
 
-   target_obj->pending_read_domains |= reloc->read_domains;
-   target_obj->pending_write_domain |= reloc->write_domain;
+   if (reloc->write_domain)
+   target->exec_entry->flags |= EXEC_OBJECT_WRITE;
+
+   /* Sandybridge PPGTT errata: We need a global gtt mapping for MI and
+* pipe_control writes because the gpu doesn't properly redirect them
+* through the ppgtt for non_secure batchbuffers.
+*/
+   if (unlikely(IS_GEN6(eb->i915) &&
+reloc->write_domain == I915_GEM_DOMAIN_INSTRUCTION)) {
+   ret = i915_vma_bind(target, target->obj->cache_level,
+   PIN_GLOBAL);
+  

[Intel-gfx] [PATCH 22/27] drm/i915: Eliminate lots of iterations over the execobjects array

[Chris Wilson]

The major scaling bottleneck in execbuffer is the processing of the
execobjects. Creating an auxiliary list is inefficient when compared to
using the execobject array we already have allocated.

Reservation is then split into phases. As we lookup up the VMA, we
try and bind it back into active location. Only if that fails, do we add
it to the unbound list for phase 2. In phase 2, we try and add all those
objects that could not fit into their previous location, with fallback
to retrying all objects and evicting the VM in case of severe
fragmentation. (This is the same as before, except that phase 1 is now
done inline with looking up the VMA to avoid an iteration over the
execobject array. In the ideal case, we eliminate the separate reservation
phase). During the reservation phase, we only evict from the VM between
passes (rather than currently as we try to fit every new VMA). In
testing with Unreal Engine's Atlantis demo which stresses the eviction
logic on gen7 class hardware, this speed up the framerate by a factor of
2.

The second loop amalgamation is between move_to_gpu and move_to_active.
As we always submit the request, even if incomplete, we can use the
current request to track active VMA as we perform the flushes and
synchronisation required.

The next big advancement is to avoid copying back to the user any
execobjects and relocations that are not changed.

v2: Add a Theory of Operation spiel.
v3: Fall back to slow relocations in preparation for flushing userptrs.
v4: Document struct members, factor out eb_validate_vma(), add a few
more comments to explain some magic and hide other magic behind macros.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h |2 +-
 drivers/gpu/drm/i915/i915_gem_evict.c   |   92 +-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c  | 1953 +--
 drivers/gpu/drm/i915/i915_vma.c |2 +-
 drivers/gpu/drm/i915/i915_vma.h |1 +
 drivers/gpu/drm/i915/selftests/i915_gem_evict.c |4 +-
 drivers/gpu/drm/i915/selftests/i915_vma.c   |   16 +-
 7 files changed, 1187 insertions(+), 883 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7b6926861e04..b0c4b9cb75c2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3558,7 +3558,7 @@ int __must_check i915_gem_evict_something(struct 
i915_address_space *vm,
 int __must_check i915_gem_evict_for_node(struct i915_address_space *vm,
 struct drm_mm_node *node,
 unsigned int flags);
-int i915_gem_evict_vm(struct i915_address_space *vm, bool do_idle);
+int i915_gem_evict_vm(struct i915_address_space *vm);
 
 /* belongs in i915_gem_gtt.h */
 static inline void i915_gem_chipset_flush(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c 
b/drivers/gpu/drm/i915/i915_gem_evict.c
index 204a2d9288ae..a193f1b36c67 100644
--- a/drivers/gpu/drm/i915/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/i915_gem_evict.c
@@ -50,6 +50,29 @@ static bool ggtt_is_idle(struct drm_i915_private *dev_priv)
return true;
 }
 
+static int ggtt_flush(struct drm_i915_private *i915)
+{
+   int err;
+
+   /* Not everything in the GGTT is tracked via vma (otherwise we
+* could evict as required with minimal stalling) so we are forced
+* to idle the GPU and explicitly retire outstanding requests in
+* the hopes that we can then remove contexts and the like only
+* bound by their active reference.
+*/
+   err = i915_gem_switch_to_kernel_context(i915);
+   if (err)
+   return err;
+
+   err = i915_gem_wait_for_idle(i915,
+I915_WAIT_INTERRUPTIBLE |
+I915_WAIT_LOCKED);
+   if (err)
+   return err;
+
+   return 0;
+}
+
 static bool
 mark_free(struct drm_mm_scan *scan,
  struct i915_vma *vma,
@@ -175,19 +198,7 @@ i915_gem_evict_something(struct i915_address_space *vm,
return intel_has_pending_fb_unpin(dev_priv) ? -EAGAIN : -ENOSPC;
}
 
-   /* Not everything in the GGTT is tracked via vma (otherwise we
-* could evict as required with minimal stalling) so we are forced
-* to idle the GPU and explicitly retire outstanding requests in
-* the hopes that we can then remove contexts and the like only
-* bound by their active reference.
-*/
-   ret = i915_gem_switch_to_kernel_context(dev_priv);
-   if (ret)
-   return ret;
-
-   ret = i915_gem_wait_for_idle(dev_priv,
-I915_WAIT_INTERRUPTIBLE |
-I915_WAIT_LOCKED);
+   ret = ggtt_flush(dev_priv);
if (ret)
return ret;
 
@@ -337,10 +348,8 @@ int i915_gem_evict_for_node(struct i915_address_s

[Intel-gfx] [PATCH 13/27] drm/i915/execlists: Pack the count into the low bits of the port.request

[Chris Wilson]

add/remove: 1/1 grow/shrink: 5/4 up/down: 391/-578 (-187)
function old new   delta
execlists_submit_ports   262 471+209
port_assign.isra   - 136+136
capture 63446359 +15
reset_common_ring438 452 +14
execlists_submit_request 228 238 +10
gen8_init_common_ring334 341  +7
intel_engine_is_idle 106 105  -1
i915_engine_info23142290 -24
__i915_gem_set_wedged_BKL485 411 -74
intel_lrc_irq_handler   17891604-185
execlists_update_context 294   --294

The most important change there is the improve to the
intel_lrc_irq_handler and excclist_submit_ports (net improvement since
execlists_update_context is now inlined).

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_debugfs.c|  32 ---
 drivers/gpu/drm/i915/i915_gem.c|   6 +-
 drivers/gpu/drm/i915/i915_gpu_error.c  |  13 ++-
 drivers/gpu/drm/i915/i915_guc_submission.c |  18 ++--
 drivers/gpu/drm/i915/intel_engine_cs.c |   2 +-
 drivers/gpu/drm/i915/intel_lrc.c   | 133 -
 drivers/gpu/drm/i915/intel_ringbuffer.h|   8 +-
 7 files changed, 120 insertions(+), 92 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 870c470177b5..0b5d7142d8d9 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3315,6 +3315,7 @@ static int i915_engine_info(struct seq_file *m, void 
*unused)
if (i915.enable_execlists) {
u32 ptr, read, write;
struct rb_node *rb;
+   unsigned int idx;
 
seq_printf(m, "\tExeclist status: 0x%08x %08x\n",
   I915_READ(RING_EXECLIST_STATUS_LO(engine)),
@@ -3332,8 +,7 @@ static int i915_engine_info(struct seq_file *m, void 
*unused)
if (read > write)
write += GEN8_CSB_ENTRIES;
while (read < write) {
-   unsigned int idx = ++read % GEN8_CSB_ENTRIES;
-
+   idx = ++read % GEN8_CSB_ENTRIES;
seq_printf(m, "\tExeclist CSB[%d]: 0x%08x, 
context: %d\n",
   idx,
   
I915_READ(RING_CONTEXT_STATUS_BUF_LO(engine, idx)),
@@ -3341,21 +3341,19 @@ static int i915_engine_info(struct seq_file *m, void 
*unused)
}
 
rcu_read_lock();
-   rq = READ_ONCE(engine->execlist_port[0].request);
-   if (rq) {
-   seq_printf(m, "\t\tELSP[0] count=%d, ",
-  engine->execlist_port[0].count);
-   print_request(m, rq, "rq: ");
-   } else {
-   seq_printf(m, "\t\tELSP[0] idle\n");
-   }
-   rq = READ_ONCE(engine->execlist_port[1].request);
-   if (rq) {
-   seq_printf(m, "\t\tELSP[1] count=%d, ",
-  engine->execlist_port[1].count);
-   print_request(m, rq, "rq: ");
-   } else {
-   seq_printf(m, "\t\tELSP[1] idle\n");
+   for (idx = 0; idx < ARRAY_SIZE(engine->execlist_port); 
idx++) {
+   unsigned int count;
+
+   rq = port_unpack(&engine->execlist_port[idx],
+&count);
+   if (rq) {
+   seq_printf(m, "\t\tELSP[%d] count=%d, ",
+  idx, count);
+   print_request(m, rq, "rq: ");
+   } else {
+   seq_printf(m, "\t\tELSP[%d] idle\n",
+  idx);
+   }
}
rcu_read_unlock();
 
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 2bc72314cdd1..f6df402a5247 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3039,12 +3039,14 @@ static void engine_set_wedged(struct intel_engine_cs 
*engine)
 */
 
if (i915.enable_execlists) {
+   struct execlist_port *port = e

[Intel-gfx] [PATCH 16/27] drm/i915: Reinstate reservation_object zapping for batch_pool objects

[Chris Wilson]

I removed the zapping of the reservation_object->fence array of shared
fences prematurely. We don't yet have the code to zap that array when
retiring the object, and so currently it remains possible to continually
grow the shared array trapping requests when reusing the batch_pool
object across many timelines.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
Cc: Mika Kuoppala 
Cc: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_gem_batch_pool.c | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_batch_pool.c 
b/drivers/gpu/drm/i915/i915_gem_batch_pool.c
index 41aa598c4f3b..414e46e2f072 100644
--- a/drivers/gpu/drm/i915/i915_gem_batch_pool.c
+++ b/drivers/gpu/drm/i915/i915_gem_batch_pool.c
@@ -114,12 +114,26 @@ i915_gem_batch_pool_get(struct i915_gem_batch_pool *pool,
list_for_each_entry(obj, list, batch_pool_link) {
/* The batches are strictly LRU ordered */
if (i915_gem_object_is_active(obj)) {
-   if (!reservation_object_test_signaled_rcu(obj->resv,
- true))
+   struct reservation_object *resv = obj->resv;
+
+   if (!reservation_object_test_signaled_rcu(resv, true))
break;
 
i915_gem_retire_requests(pool->engine->i915);
GEM_BUG_ON(i915_gem_object_is_active(obj));
+
+   /* The object is now idle, clear the array of shared
+* fences before we add a new request. Although, we
+* remain on the same engine, we may be on a different
+* timeline and so may continually grow the array,
+* trapping a reference to all the old fences, rather
+* than replace the existing fence.
+*/
+   if (rcu_access_pointer(resv->fence)) {
+   reservation_object_lock(resv, NULL);
+   reservation_object_add_excl_fence(resv, NULL);
+   reservation_object_unlock(resv);
+   }
}
 
GEM_BUG_ON(!reservation_object_test_signaled_rcu(obj->resv,
-- 
2.11.0

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

[Intel-gfx] [PATCH 15/27] drm/i915: Split execlist priority queue into rbtree + linked list

[Chris Wilson]

All the requests at the same priority are executed in FIFO order. They
do not need to be stored in the rbtree themselves, as they are a simple
list within a level. If we move the requests at one priority into a list,
we can then reduce the rbtree to the set of priorities. This should keep
the height of the rbtree small, as the number of active priorities can not
exceed the number of active requests and should be typically only a few.

Currently, we have ~2k possible different priority levels, that may
increase to allow even more fine grained selection. Allocating those in
advance seems a waste (and may be impossible), so we opt for allocating
upon first use, and freeing after its requests are depleted. To avoid
the possibility of an allocation failure causing us to lose a request,
we preallocate the default priority (0) and bump any request to that
priority if we fail to allocate it the appropriate plist. Having a
request (that is ready to run, so not leading to corruption) execute
out-of-order is better than leaking the request (and its dependency
tree) entirely.

There should be a benefit to reducing execlists_dequeue() to principally
using a simple list (and reducing the frequency of both rbtree iteration
and balancing on erase) but for typical workloads, request coalescing
should be small enough that we don't notice any change. The main gain is
from improving PI calls to schedule, and the explicit list within a
level should make request unwinding simpler (we just need to insert at
the head of the list rather than the tail and not have to make the
rbtree search more complicated).

v2: Avoid use-after-free when deleting a depleted priolist

Signed-off-by: Chris Wilson 
Cc: Michał Winiarski 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_debugfs.c| 12 +++--
 drivers/gpu/drm/i915/i915_gem_request.c|  4 +-
 drivers/gpu/drm/i915/i915_gem_request.h|  2 +-
 drivers/gpu/drm/i915/i915_guc_submission.c | 20 ++--
 drivers/gpu/drm/i915/intel_lrc.c   | 75 ++
 drivers/gpu/drm/i915/intel_ringbuffer.h|  7 +++
 6 files changed, 90 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 0b5d7142d8d9..a8c7788d986e 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3314,7 +3314,6 @@ static int i915_engine_info(struct seq_file *m, void 
*unused)
 
if (i915.enable_execlists) {
u32 ptr, read, write;
-   struct rb_node *rb;
unsigned int idx;
 
seq_printf(m, "\tExeclist status: 0x%08x %08x\n",
@@ -3358,9 +3357,14 @@ static int i915_engine_info(struct seq_file *m, void 
*unused)
rcu_read_unlock();
 
spin_lock_irq(&engine->timeline->lock);
-   for (rb = engine->execlist_first; rb; rb = rb_next(rb)) 
{
-   rq = rb_entry(rb, typeof(*rq), priotree.node);
-   print_request(m, rq, "\t\tQ ");
+   for (rb = engine->execlist_first; rb; rb = rb_next(rb)){
+   struct execlist_priolist *plist =
+   rb_entry(rb, typeof(*plist), node);
+
+   list_for_each_entry(rq,
+   &plist->requests,
+   priotree.link)
+   print_request(m, rq, "\t\tQ ");
}
spin_unlock_irq(&engine->timeline->lock);
} else if (INTEL_GEN(dev_priv) > 6) {
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 83b1584b3deb..59c0e0b00028 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -159,7 +159,7 @@ i915_priotree_fini(struct drm_i915_private *i915, struct 
i915_priotree *pt)
 {
struct i915_dependency *dep, *next;
 
-   GEM_BUG_ON(!RB_EMPTY_NODE(&pt->node));
+   GEM_BUG_ON(!list_empty(&pt->link));
 
/* Everyone we depended upon (the fences we wait to be signaled)
 * should retire before us and remove themselves from our list.
@@ -185,7 +185,7 @@ i915_priotree_init(struct i915_priotree *pt)
 {
INIT_LIST_HEAD(&pt->signalers_list);
INIT_LIST_HEAD(&pt->waiters_list);
-   RB_CLEAR_NODE(&pt->node);
+   INIT_LIST_HEAD(&pt->link);
pt->priority = INT_MIN;
 }
 
diff --git a/drivers/gpu/drm/i915/i915_gem_request.h 
b/drivers/gpu/drm/i915/i915_gem_request.h
index 4ccab5affd3c..0a1d717b9fa7 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.h
+++ b/drivers/gpu/drm/i915/i915_gem_request.h
@@ -67,7 +67,7 @@ struct i915_dependency {
 struct i915_priotree {
struct list_head signalers_list; /* those b

[Intel-gfx] [PATCH 14/27] drm/i915: Don't mark an execlists context-switch when idle

[Chris Wilson]

If we *know* that the engine is idle, i.e. we have not more contexts in
lift, we can skip any spurious CSB idle interrupts. These spurious
interrupts seem to arrive long after we assert that the engines are
completely idle, triggering later assertions:

[  178.896646] intel_engine_is_idle(bcs): interrupt not handled, irq_posted=2
[  178.896655] [ cut here ]
[  178.896658] kernel BUG at drivers/gpu/drm/i915/intel_engine_cs.c:226!
[  178.896661] invalid opcode:  [#1] SMP
[  178.896663] Modules linked in: i915(E) x86_pkg_temp_thermal(E) 
crct10dif_pclmul(E) crc32_pclmul(E) crc32c_intel(E) ghash_clmulni_intel(E) 
nls_ascii(E) nls_cp437(E) vfat(E) fat(E) intel_gtt(E) i2c_algo_bit(E) 
drm_kms_helper(E) syscopyarea(E) sysfillrect(E) sysimgblt(E) fb_sys_fops(E) 
aesni_intel(E) prime_numbers(E) evdev(E) aes_x86_64(E) drm(E) crypto_simd(E) 
cryptd(E) glue_helper(E) mei_me(E) mei(E) lpc_ich(E) efivars(E) mfd_core(E) 
battery(E) video(E) acpi_pad(E) button(E) tpm_tis(E) tpm_tis_core(E) tpm(E) 
autofs4(E) i2c_i801(E) fan(E) thermal(E) i2c_designware_platform(E) 
i2c_designware_core(E)
[  178.896694] CPU: 1 PID: 522 Comm: gem_exec_whispe Tainted: GE   
4.11.0-rc5+ #14
[  178.896702] task: 88040aba8d40 task.stack: c93f
[  178.896722] RIP: 0010:intel_engine_init_global_seqno+0x1db/0x1f0 [i915]
[  178.896725] RSP: 0018:c93f3ab0 EFLAGS: 00010246
[  178.896728] RAX:  RBX: 88040af54000 RCX: 
[  178.896731] RDX: 88041ec933e0 RSI: 88041ec8cc48 RDI: 88041ec8cc48
[  178.896734] RBP: c93f3ac8 R08:  R09: 047d
[  178.896736] R10: 0040 R11: 88040b344f80 R12: 
[  178.896739] R13: 88040bce R14: 88040bce52d8 R15: 88040bce
[  178.896742] FS:  7f22d8c0() GS:88041ec8() 
knlGS:
[  178.896746] CS:  0010 DS:  ES:  CR0: 80050033
[  178.896749] CR2: 7f41ddd8f000 CR3: 00040bb03000 CR4: 001406e0
[  178.896752] Call Trace:
[  178.896768]  reset_all_global_seqno.part.33+0x4e/0xd0 [i915]
[  178.896782]  i915_gem_request_alloc+0x304/0x330 [i915]
[  178.896795]  i915_gem_do_execbuffer+0x8a1/0x17d0 [i915]
[  178.896799]  ? remove_wait_queue+0x48/0x50
[  178.896812]  ? i915_wait_request+0x300/0x590 [i915]
[  178.896816]  ? wake_up_q+0x70/0x70
[  178.896819]  ? refcount_dec_and_test+0x11/0x20
[  178.896823]  ? reservation_object_add_excl_fence+0xa5/0x100
[  178.896835]  i915_gem_execbuffer2+0xab/0x1f0 [i915]
[  178.896844]  drm_ioctl+0x1e6/0x460 [drm]
[  178.896858]  ? i915_gem_execbuffer+0x260/0x260 [i915]
[  178.896862]  ? dput+0xcf/0x250
[  178.896866]  ? full_proxy_release+0x66/0x80
[  178.896869]  ? mntput+0x1f/0x30
[  178.896872]  do_vfs_ioctl+0x8f/0x5b0
[  178.896875]  ? fput+0x9/0x10
[  178.896878]  ? task_work_run+0x80/0xa0
[  178.896881]  SyS_ioctl+0x3c/0x70
[  178.896885]  entry_SYSCALL_64_fastpath+0x17/0x98
[  178.896888] RIP: 0033:0x7f2ccb455ca7
[  178.896890] RSP: 002b:7ffcabec72d8 EFLAGS: 0246 ORIG_RAX: 
0010
[  178.896894] RAX: ffda RBX: 55f897a44b90 RCX: 7f2ccb455ca7
[  178.896897] RDX: 7ffcabec74a0 RSI: 40406469 RDI: 0003
[  178.896900] RBP: 7f2ccb70a440 R08: 7f2ccb70d0a4 R09: 
[  178.896903] R10:  R11: 0246 R12: 
[  178.896905] R13: 55f89782d71a R14: 7ffcabecf838 R15: 0003
[  178.896908] Code: 00 31 d2 4c 89 ef 8d 70 48 41 ff 95 f8 06 00 00 e9 68 fe 
ff ff be 0f 00 00 00 48 c7 c7 48 dc 37 a0 e8 fa 33 d6 e0 e9 0b ff ff ff <0f> 0b 
0f 0b 0f 0b 0f 0b 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00

On the other hand, by ignoring the interrupt do we risk running out of
space in CSB ring? Testing for a few hours suggests not, i.e. that we
only seem to get the odd delayed CSB idle notification.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_irq.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index fd97fe00cd0d..fb2ac202dec5 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1359,8 +1359,10 @@ gen8_cs_irq_handler(struct intel_engine_cs *engine, u32 
iir, int test_shift)
bool tasklet = false;
 
if (iir & (GT_CONTEXT_SWITCH_INTERRUPT << test_shift)) {
-   set_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
-   tasklet = true;
+   if (port_count(&engine->execlist_port[0])) {
+   set_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
+   tasklet = true;
+   }
}
 
if (iir & (GT_RENDER_USER_INTERRUPT << test_shift)) {
-- 
2.11.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mai

[Intel-gfx] [PATCH 09/27] drm/i915: Confirm the request is still active before adding it to the await

[Chris Wilson]

Although we do check the completion-status of the request before
actually adding a wait on it (either to its submit fence or its
completion dma-fence), we currently do not check before adding it to the
dependency lists.

Signed-off-by: Chris Wilson 
Reviewed-by: Michał Winiarski 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_request.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 1f3620ab4736..d5fadf53f153 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -681,6 +681,9 @@ i915_gem_request_await_request(struct drm_i915_gem_request 
*to,
GEM_BUG_ON(to == from);
GEM_BUG_ON(to->timeline == from->timeline);
 
+   if (i915_gem_request_completed(from))
+   return 0;
+
if (to->engine->schedule) {
ret = i915_priotree_add_dependency(to->i915,
   &to->priotree,
-- 
2.11.0

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

[Intel-gfx] [PATCH 12/27] drm/i915: Only report a wakeup if the waiter was truly asleep

[Chris Wilson]

If we attempt to wake up a waiter, who is currently checking the seqno
it will be in the TASK_INTERRUPTIBLE state and ttwu will report success.
However, it is actually awake and functioning -- so delay reporting the
actual wake up until it sleeps.

v2: Defend against !CONFIG_SMP
v3: Don't filter out calls to wake_up_process

References: https://bugs.freedesktop.org/show_bug.cgi?id=17
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_breadcrumbs.c | 18 --
 drivers/gpu/drm/i915/intel_ringbuffer.h  |  4 
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index 9ccbf26124c6..808d3a3cda0a 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -27,6 +27,12 @@
 
 #include "i915_drv.h"
 
+#ifdef CONFIG_SMP
+#define task_asleep(tsk) (!(tsk)->on_cpu)
+#else
+#define task_asleep(tsk) ((tsk) != current)
+#endif
+
 static unsigned int __intel_breadcrumbs_wakeup(struct intel_breadcrumbs *b)
 {
struct intel_wait *wait;
@@ -37,8 +43,16 @@ static unsigned int __intel_breadcrumbs_wakeup(struct 
intel_breadcrumbs *b)
wait = b->irq_wait;
if (wait) {
result = ENGINE_WAKEUP_WAITER;
-   if (wake_up_process(wait->tsk))
+
+   /* Be careful not to report a successful wakeup if the waiter
+* is currently processing the seqno, where it will have
+* already called set_task_state(TASK_INTERRUPTIBLE).
+*/
+   if (task_asleep(wait->tsk))
result |= ENGINE_WAKEUP_ASLEEP;
+
+   if (wake_up_process(wait->tsk))
+   result |= ENGINE_WAKEUP_SUCCESS;
}
 
return result;
@@ -98,7 +112,7 @@ static void intel_breadcrumbs_hangcheck(unsigned long data)
 * but we still have a waiter. Assuming all batches complete within
 * DRM_I915_HANGCHECK_JIFFIES [1.5s]!
 */
-   if (intel_engine_wakeup(engine) & ENGINE_WAKEUP_ASLEEP) {
+   if (intel_engine_wakeup(engine) == ENGINE_WAKEUP) {
missed_breadcrumb(engine);
mod_timer(&engine->breadcrumbs.fake_irq, jiffies + 1);
} else {
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 00d36aa4e26d..d25b88467e5e 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -668,6 +668,10 @@ static inline bool intel_engine_has_waiter(const struct 
intel_engine_cs *engine)
 unsigned int intel_engine_wakeup(struct intel_engine_cs *engine);
 #define ENGINE_WAKEUP_WAITER BIT(0)
 #define ENGINE_WAKEUP_ASLEEP BIT(1)
+#define ENGINE_WAKEUP_SUCCESS BIT(2)
+#define ENGINE_WAKEUP (ENGINE_WAKEUP_WAITER | \
+  ENGINE_WAKEUP_ASLEEP | \
+  ENGINE_WAKEUP_SUCCESS)
 
 void __intel_engine_disarm_breadcrumbs(struct intel_engine_cs *engine);
 void intel_engine_disarm_breadcrumbs(struct intel_engine_cs *engine);
-- 
2.11.0

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

[Intel-gfx] [PATCH 10/27] drm/i915: Do not record a successful syncpoint for a dma-await

[Chris Wilson]

As we may unwind the requests, even though the request we are awaiting
has a global_seqno that seqno may be revoked during the await and so we
can not reliably use it as a barrier for all future awaits on the same
timeline.

Signed-off-by: Chris Wilson 
Cc: Michał Winiarski 
Reviewed-by: Michał Winiarski 
---
 drivers/gpu/drm/i915/i915_gem_request.c | 34 -
 1 file changed, 16 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index d5fadf53f153..75b33993468f 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -700,33 +700,31 @@ i915_gem_request_await_request(struct 
drm_i915_gem_request *to,
}
 
seqno = i915_gem_request_global_seqno(from);
-   if (!seqno) {
-   ret = i915_sw_fence_await_dma_fence(&to->submit,
-   &from->fence, 0,
-   GFP_KERNEL);
-   return ret < 0 ? ret : 0;
-   }
+   if (!seqno)
+   goto await_dma_fence;
 
-   if (seqno <= to->timeline->global_sync[from->engine->id])
-   return 0;
-
-   trace_i915_gem_ring_sync_to(to, from);
if (!i915.semaphores) {
-   if (!i915_spin_request(from, TASK_INTERRUPTIBLE, 2)) {
-   ret = i915_sw_fence_await_dma_fence(&to->submit,
-   &from->fence, 0,
-   GFP_KERNEL);
-   if (ret < 0)
-   return ret;
-   }
+   if (!__i915_spin_request(from, seqno, TASK_INTERRUPTIBLE, 2))
+   goto await_dma_fence;
} else {
+   if (seqno <= to->timeline->global_sync[from->engine->id])
+   return 0;
+
+   trace_i915_gem_ring_sync_to(to, from);
ret = to->engine->semaphore.sync_to(to, from);
if (ret)
return ret;
+
+   to->timeline->global_sync[from->engine->id] = seqno;
}
 
-   to->timeline->global_sync[from->engine->id] = seqno;
return 0;
+
+await_dma_fence:
+   ret = i915_sw_fence_await_dma_fence(&to->submit,
+   &from->fence, 0,
+   GFP_KERNEL);
+   return ret < 0 ? ret : 0;
 }
 
 int
-- 
2.11.0

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