[Intel-gfx] ✓ Fi.CI.IGT: success for drm/fbdev: Panel orientation connector property support (rev2)

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

Series: drm/fbdev: Panel orientation connector property support (rev2)
URL   : https://patchwork.freedesktop.org/series/32447/
State : success

== Summary ==

Test drv_module_reload:
Subgroup basic-reload-inject:
dmesg-warn -> PASS   (shard-hsw) fdo#102707 +1
Test kms_busy:
Subgroup extended-modeset-hang-oldfb-with-reset-render-A:
dmesg-warn -> PASS   (shard-hsw) fdo#102249
Test perf:
Subgroup polling:
fail   -> PASS   (shard-hsw) fdo#102252

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

shard-hswtotal:2540 pass:1433 dwarn:2   dfail:0   fail:8   skip:1097 
time:9171s

== Logs ==

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


Re: [Intel-gfx] [PATCH 2/4] drm/i915: Synchronize irq before parking each engine

2017-10-24 Thread Chris Wilson
Quoting Chris Wilson (2017-10-23 22:32:35)
> When we park the engine (upon idling), we kill the irq tasklet. However,
> to be sure that it is not restarted by a final interrupt after doing so,
> flush the interrupt handler before parking. As we only park the engines
> when we believe the system is idle, there should not be any spurious
> interrupts later to distrub us; so flushing the final in-flight
> interrupt should be sufficient.

And even this is not enough for some mischievous hw:

<4>[  329.637536] WARN_ON(!engine->i915->gt.awake)
<4>[  329.637551] [ cut here ]
<4>[  329.637569] WARNING: CPU: 3 PID: 74 at 
drivers/gpu/drm/i915/i915_irq.c:1394 gen8_cs_irq_handler+0x7c/0xe0 [i915]
<4>[  329.637571] Modules linked in: vgem snd_hda_codec_hdmi 
snd_hda_codec_realtek snd_hda_codec_generic i915 snd_hda_intel snd_hda_codec 
snd_hwdep x86_pkg_temp_thermal intel_powerclamp snd_hda_core coretemp 
crct10dif_pclmul crc32_pclmul ghash_clmulni_intel e1000e snd_pcm ptp pps_core 
mei_me prime_numbers mei pinctrl_sunrisepoint pinctrl_intel i2c_hid
<4>[  329.637605] CPU: 3 PID: 74 Comm: kworker/u8:1 Tainted: G U  
4.14.0-rc6-CI-Patchwork_6149+ #1
<4>[  329.637606] Hardware name:  /NUC7i5BNB, BIOS 
BNKBL357.86A.0048.2017.0704.1415 07/04/2017
<4>[  329.637624] Workqueue: i915 i915_gem_idle_work_handler [i915]
<4>[  329.637627] task: 880272ff2880 task.stack: c963c000
<4>[  329.637640] RIP: 0010:gen8_cs_irq_handler+0x7c/0xe0 [i915]
<4>[  329.637642] RSP: 0018:88027ed83e30 EFLAGS: 00010086
<4>[  329.637644] RAX: 0020 RBX: 8802698a8008 RCX: 
00010002
<4>[  329.637645] RDX:  RSI: 81d0dbdc RDI: 
81cc1b56
<4>[  329.637647] RBP: 88027ed83e60 R08:  R09: 
0001
<4>[  329.637648] R10: d8873c29 R11: 148e3c06 R12: 
0100
<4>[  329.637650] R13: 88026924 R14: 0092 R15: 
88026a6a6918
<4>[  329.637651] FS:  () GS:88027ed8() 
knlGS:
<4>[  329.637653] CS:  0010 DS:  ES:  CR0: 80050033
<4>[  329.637654] CR2: 7f099468d198 CR3: 03e0f002 CR4: 
003606e0
<4>[  329.637655] Call Trace:
<4>[  329.637657]  
<4>[  329.637672]  gen8_gt_irq_handler+0x102/0x120 [i915]
<4>[  329.637685]  gen8_irq_handler+0x90/0x670 [i915]
<4>[  329.637690]  __handle_irq_event_percpu+0x49/0x350
<4>[  329.637694]  handle_irq_event_percpu+0x23/0x60
<4>[  329.637696]  handle_irq_event+0x39/0x60
<4>[  329.637699]  handle_edge_irq+0xf4/0x1c0
<4>[  329.637702]  handle_irq+0x1a/0x30
<4>[  329.637704]  do_IRQ+0x68/0x130
<4>[  329.637707]  common_interrupt+0x9a/0x9a
<4>[  329.637709]  
<4>[  329.637711] RIP: 0010:_raw_spin_unlock_irq+0x32/0x50
<4>[  329.637712] RSP: 0018:c963fda8 EFLAGS: 0206 ORIG_RAX: 
ff6d
<4>[  329.637715] RAX: 880272ff2880 RBX: 8802692443e0 RCX: 
0006
<4>[  329.637716] RDX: 1379 RSI: 81d0dbdc RDI: 
0001
<4>[  329.637718] RBP: c963fdb0 R08: 880272ff3190 R09: 

<4>[  329.637719] R10:  R11:  R12: 
8802692443e0
<4>[  329.637720] R13: 880269240070 R14: 880269247358 R15: 
81e40e00
<4>[  329.637726]  ? _raw_spin_unlock_irq+0x2c/0x50
<4>[  329.637739]  gen6_disable_rps_interrupts+0x62/0x90 [i915]
<4>[  329.637753]  gen6_rps_idle+0x1d/0xe0 [i915]
<4>[  329.637770]  i915_gem_idle_work_handler+0x188/0x190 [i915]
<4>[  329.637773]  process_one_work+0x221/0x650
<4>[  329.63]  worker_thread+0x1db/0x3b0
<4>[  329.637781]  kthread+0x114/0x150
<4>[  329.637783]  ? process_one_work+0x650/0x650
<4>[  329.637785]  ? kthread_create_on_node+0x40/0x40
<4>[  329.637788]  ret_from_fork+0x27/0x40
<4>[  329.637792] Code: 48 83 c4 20 5b 41 5c 5d c3 48 8b 07 80 b8 cc 81 00 00 
00 75 42 48 c7 c6 f0 27 29 a0 48 c7 c7 3e 48 28 a0 89 55 d4 e8 b5 ca f9 e0 <0f> 
ff 48 8b 03 48 8d 75 d8 48 89 df 48 c7 45 d8 e0 78 60 81 48 
<4>[  329.637867] ---[ end trace e6209c9962196e53 ]---
<6>[  329.637870] i915 :00:02.0: [drm] rcs0
<6>[  329.637872] i915 :00:02.0: [drm]  current seqno 88f5, last 88f5, 
hangcheck 0 [29638 ms], inflight 0
<6>[  329.637874] i915 :00:02.0: [drm]  Reset count: 2
<6>[  329.637876] i915 :00:02.0: [drm]  Requests:
<6>[  329.637887] i915 :00:02.0: [drm]  RING_START: 0xf000 
[0x]
<6>[  329.637889] i915 :00:02.0: [drm]  RING_HEAD:  0x0c10 
[0x]
<6>[  329.637891] i915 :00:02.0: [drm]  RING_TAIL:  0x0c10 
[0x]
<6>[  329.637894] i915 :00:02.0: [drm]  RING_CTL:   0x3000 []
<6>[  329.637897] i915 :00:02.0: [drm]  ACTHD:  0x_0c10
<6>[  329.637900] i915 :00:02.0: [drm]  BBADDR: 0x_0004
<6>[  329.637902] i915 :00:02.0: [drm]  Execlist status: 0x0301 

<6>[  329.637904] i915 :00:02.0: [drm]

[Intel-gfx] [PATCH i-g-t 1/2] meson: don't assume xmlrpc-c-config is there

2017-10-24 Thread Jani Nikula
xmlrpc is an optional dependency. If pkg-config can't find it, don't
assume xmlrpc-c-config will be there either. Make xmlrpc-c-config
optional too.

Fixes error:

Meson encountered an error in file meson.build, line 73, column 1:
Program or command 'xmlrpc-c-config' not foundor not executable

Fixes: 892abc602a8a ("meson: Add fallback for xmlrpc discovery")
Cc: Arkadiusz Hiler 
Signed-off-by: Jani Nikula 

---

Note: Untested in the scenario described in 892abc602a8a ("meson: Add
fallback for xmlrpc discovery")
---
 meson.build | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/meson.build b/meson.build
index ac991c2f9bf2..fb81c4dbbd55 100644
--- a/meson.build
+++ b/meson.build
@@ -69,9 +69,10 @@ xmlrpc = dependency('xmlrpc', required : false)
 xmlrpc_util = dependency('xmlrpc_util', required : false)
 xmlrpc_client = dependency('xmlrpc_client', required : false)
 
-if not xmlrpc.found()
-   libs_cmd = run_command('xmlrpc-c-config', 'client', '--libs')
-   cflags_cmd = run_command('xmlrpc-c-config', 'client', '--cflags')
+xmlrpc_cmd = find_program('xmlrpc-c-config', required : false)
+if not xmlrpc.found() and xmlrpc_cmd.found()
+   libs_cmd = run_command(xmlrpc_cmd, 'client', '--libs')
+   cflags_cmd = run_command(xmlrpc_cmd, 'client', '--cflags')
 
if libs_cmd.returncode() == 0 and cflags_cmd.returncode() == 0
xmlrpc = declare_dependency(compile_args: 
cflags_cmd.stdout().strip().split(),
-- 
2.11.0

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


[Intel-gfx] [PATCH i-g-t 2/2] meson: intel_dp_compliance depends on libudev

2017-10-24 Thread Jani Nikula
Only build intel_dp_compliance when libudev is available, also include
libudev in the list of dependencies.

Fixes error when libudev isn't there:

../tools/intel_dp_compliance_hotplug.c:33:21: fatal error: libudev.h: No such 
file or directory
 #include 

Signed-off-by: Jani Nikula 
---
 tools/meson.build | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/tools/meson.build b/tools/meson.build
index 1bacac58647a..7fc5390a6f63 100644
--- a/tools/meson.build
+++ b/tools/meson.build
@@ -57,10 +57,15 @@ endforeach
 
 pkgdatadir = join_paths(get_option('prefix'), get_option('datadir'), 
'intel-gpu-tools')
 
-intel_dp_compliance_src = [ 'intel_dp_compliance.c', 
'intel_dp_compliance_hotplug.c' ]
-executable('intel_dp_compliance', sources : intel_dp_compliance_src,
-  dependencies : tool_deps,
-  install : true)
+if libudev.found()
+   intel_dp_compliance_src = [
+   'intel_dp_compliance.c',
+   'intel_dp_compliance_hotplug.c'
+   ]
+   executable('intel_dp_compliance', sources : intel_dp_compliance_src,
+  dependencies : [tool_deps, libudev],
+  install : true)
+endif
 
 intel_l3_parity_src = [ 'intel_l3_parity.c', 'intel_l3_udev_listener.c' ]
 executable('intel_l3_parity', sources : intel_l3_parity_src,
-- 
2.11.0

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


[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] meson: don't assume xmlrpc-c-config is there

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

Series: series starting with [1/2] meson: don't assume xmlrpc-c-config is there
URL   : https://patchwork.freedesktop.org/series/32511/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
cdfe992134b478b76e0763773e9d4e82bba5b98f tests/kms_plane_lowres: Rework tests 
to work without fbcon, v3.

with latest DRM-Tip kernel build CI_DRM_3276
5c82a37eff83 drm-tip: 2017y-10m-23d-18h-06m-28s UTC integration manifest

No testlist changes.

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:434s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:455s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:370s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:531s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:264s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:509s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:498s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:497s
fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
time:481s
fi-cfl-s total:289  pass:253  dwarn:4   dfail:0   fail:0   skip:32  
time:563s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:408s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:251s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:588s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:433s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:426s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:433s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:494s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:462s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:493s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:571s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:480s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:591s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:540s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:450s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:651s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:521s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:504s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:458s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:566s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:419s

== Logs ==

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


Re: [Intel-gfx] [PATCH 2/4] drm/i915: Synchronize irq before parking each engine

2017-10-24 Thread Chris Wilson
Quoting Chris Wilson (2017-10-23 22:32:35)
> When we park the engine (upon idling), we kill the irq tasklet. However,
> to be sure that it is not restarted by a final interrupt after doing so,
> flush the interrupt handler before parking. As we only park the engines
> when we believe the system is idle, there should not be any spurious
> interrupts later to distrub us; so flushing the final in-flight
> interrupt should be sufficient.
> 
> Signed-off-by: Chris Wilson 
> Cc: Joonas Lahtinen 
> Cc: Mika Kuoppala 
> Cc: Imre Deak 
> ---
>  drivers/gpu/drm/i915/i915_gem.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index bb0e85043e01..b547a6327d34 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3327,6 +3327,12 @@ i915_gem_idle_work_handler(struct work_struct *work)
> if (new_requests_since_last_retire(dev_priv))
> goto out_unlock;
>  
> +   /*
> +* Be paranoid and flush a concurrent interrupt to make sure
> +* we don't reactivate any irq tasklets after parking.

* FIXME: Note that even though we have waited for execlists to be idle,
* there may still be an in-flight interrupt even though the CSB
* is now empty. synchronize_irq() makes sure that the residual
* interrupt is completed before we continue, but it doesn't prevent
* the HW from raising that residual interrupt later. To complete
* the shield we should coordinate disabling the CS irq with
* flushing the residual interrupt.

> +*/
> +   synchronize_irq(dev_priv->drm.irq);
> +
> /*
>  * We are committed now to parking the engines, make sure there
>  * will be no more interrupts arriving later.
> -- 
> 2.15.0.rc1
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] meson: don't assume xmlrpc-c-config is there

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

Series: series starting with [1/2] meson: don't assume xmlrpc-c-config is there
URL   : https://patchwork.freedesktop.org/series/32511/
State : success

== Summary ==

Test drv_module_reload:
Subgroup basic-reload:
pass   -> DMESG-WARN (shard-hsw) fdo#102707
Test kms_busy:
Subgroup extended-modeset-hang-oldfb-with-reset-render-A:
dmesg-warn -> PASS   (shard-hsw) fdo#102249
Test perf:
Subgroup polling:
fail   -> PASS   (shard-hsw) fdo#102252
Test kms_setmode:
Subgroup basic:
pass   -> FAIL   (shard-hsw) fdo#99912

fdo#102707 https://bugs.freedesktop.org/show_bug.cgi?id=102707
fdo#102249 https://bugs.freedesktop.org/show_bug.cgi?id=102249
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912

shard-hswtotal:2540 pass:1431 dwarn:3   dfail:0   fail:9   skip:1097 
time:9254s

== Logs ==

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


Re: [Intel-gfx] [PATCH 2/4] drm/i915: Synchronize irq before parking each engine

2017-10-24 Thread Mika Kuoppala
Chris Wilson  writes:

> Quoting Chris Wilson (2017-10-23 22:32:35)
>> When we park the engine (upon idling), we kill the irq tasklet. However,
>> to be sure that it is not restarted by a final interrupt after doing so,
>> flush the interrupt handler before parking. As we only park the engines
>> when we believe the system is idle, there should not be any spurious
>> interrupts later to distrub us; so flushing the final in-flight
>> interrupt should be sufficient.
>> 
>> Signed-off-by: Chris Wilson 
>> Cc: Joonas Lahtinen 
>> Cc: Mika Kuoppala 
>> Cc: Imre Deak 
>> ---
>>  drivers/gpu/drm/i915/i915_gem.c | 6 ++
>>  1 file changed, 6 insertions(+)
>> 
>> diff --git a/drivers/gpu/drm/i915/i915_gem.c 
>> b/drivers/gpu/drm/i915/i915_gem.c
>> index bb0e85043e01..b547a6327d34 100644
>> --- a/drivers/gpu/drm/i915/i915_gem.c
>> +++ b/drivers/gpu/drm/i915/i915_gem.c
>> @@ -3327,6 +3327,12 @@ i915_gem_idle_work_handler(struct work_struct *work)
>> if (new_requests_since_last_retire(dev_priv))
>> goto out_unlock;
>>  
>> +   /*
>> +* Be paranoid and flush a concurrent interrupt to make sure
>> +* we don't reactivate any irq tasklets after parking.
>
> * FIXME: Note that even though we have waited for execlists to be idle,
> * there may still be an in-flight interrupt even though the CSB
> * is now empty. synchronize_irq() makes sure that the residual
> * interrupt is completed before we continue, but it doesn't prevent
> * the HW from raising that residual interrupt later. To complete
> * the shield we should coordinate disabling the CS irq with
> * flushing the residual interrupt.

Apparently tasklet_kill is 'broken' in a sence that
yeah new schedule reanimates the dead one. This
seems weird guarantee for an api of such name and
someone has even tried to fix it:

https://patchwork.kernel.org/patch/9298717/

I am pondering that can we combine the tasklet_disable
into the mix. We would just defer the tasklet until
we are ready and willing to process again?

-Mika

>
>> +*/
>> +   synchronize_irq(dev_priv->drm.irq);
>> +
>> /*
>>  * We are committed now to parking the engines, make sure there
>>  * will be no more interrupts arriving later.
>> -- 
>> 2.15.0.rc1
>> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915/cnl: Force DDI_A_4_LANES when needed.

2017-10-24 Thread Ville Syrjälä
On Mon, Oct 23, 2017 at 10:39:20AM -0700, Rodrigo Vivi wrote:
> As we faced in BXT, on CNL DDI_A_4_LANES is not
> set as expected when system is boot with multiple
> monitors connected. This result in wrong lane
> setup impacting the max data rate available and
> consequently blocking modeset on eDP, resulting
> in a blank screen.
> 
> Most of CNL SKUs don't support DDI-E.
> The only SKU that supports DDI-E is the same
> that supports the full A/E split called DDI-F.
> 
> Also when DDI-F is used DDI-E cannot be used because
> they share Interrupts. So DDI-E is almost useless.
> Anyways let's consider this is possible and rely on
> VBT for that.
> 
> This patch was initialy start by Clint, but required
> many changes including full commit message. So
> Credits entirely to Clint for finding this.
> 
> v2: Extract all messy conditions into a helper function
> as suggested by Ville.
> Along with simplification I removed the debug
> message on the working case since now all conditions
> are grouped.
> v3: Split the conditions even more as suggested by Ville.
> Get's cleaner and easier to add new cases in the
> future.
> 
> Suggested-by: Clint Taylor 
> Cc: Clint Taylor 
> Cc: Mika Kahola 
> Cc: Jani Nikula 
> Cc: Ville Syrjälä 
> Signed-off-by: Rodrigo Vivi 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/intel_ddi.c | 46 
> ++--
>  1 file changed, 35 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index adf51b328844..38a7088bd39c 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2694,6 +2694,34 @@ intel_ddi_init_hdmi_connector(struct 
> intel_digital_port *intel_dig_port)
>   return connector;
>  }
>  
> +static bool intel_ddi_a_force_4_lanes(struct intel_digital_port *dport)
> +{
> + struct drm_i915_private *dev_priv = to_i915(dport->base.base.dev);
> +
> + if (dport->port != PORT_A)
> + return false;
> +
> + if (dport->saved_port_bits & DDI_A_4_LANES)
> + return false;
> +
> + /* Broxton/Geminilake: Bspec says that DDI_A_4_LANES is the only
> +  * supported configuration
> +  */
> + if (IS_GEN9_LP(dev_priv))
> + return true;
> +
> + /* Cannonlake: Most of SKUs don't support DDI_E, and the only
> +  * one who does also have a full A/E split called
> +  * DDI_F what makes DDI_E useless. However for this
> +  * case let's trust VBT info.
> +  */
> + if (IS_CANNONLAKE(dev_priv) &&
> + !intel_bios_is_port_present(dev_priv, PORT_E))
> + return true;
> +
> + return false;
> +}
> +
>  void intel_ddi_init(struct drm_i915_private *dev_priv, enum port port)
>  {
>   struct intel_digital_port *intel_dig_port;
> @@ -2803,18 +2831,14 @@ void intel_ddi_init(struct drm_i915_private 
> *dev_priv, enum port port)
>   }
>  
>   /*
> -  * Bspec says that DDI_A_4_LANES is the only supported configuration
> -  * for Broxton.  Yet some BIOS fail to set this bit on port A if eDP
> -  * wasn't lit up at boot.  Force this bit on in our internal
> -  * configuration so that we use the proper lane count for our
> -  * calculations.
> +  * Some BIOS might fail to set this bit on port A if eDP
> +  * wasn't lit up at boot.  Force this bit set when needed
> +  * so we use the proper lane count for our calculations.
>*/
> - if (IS_GEN9_LP(dev_priv) && port == PORT_A) {
> - if (!(intel_dig_port->saved_port_bits & DDI_A_4_LANES)) {
> - DRM_DEBUG_KMS("BXT BIOS forgot to set DDI_A_4_LANES for 
> port A; fixing\n");
> - intel_dig_port->saved_port_bits |= DDI_A_4_LANES;
> - max_lanes = 4;
> - }
> + if (intel_ddi_a_force_4_lanes(intel_dig_port)) {
> + DRM_DEBUG_KMS("Forcing DDI_A_4_LANES for port A\n");
> + intel_dig_port->saved_port_bits |= DDI_A_4_LANES;
> + max_lanes = 4;
>   }
>  
>   intel_dig_port->max_lanes = max_lanes;
> -- 
> 2.13.5

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


Re: [Intel-gfx] [PATCH 2/4] drm/i915: Synchronize irq before parking each engine

2017-10-24 Thread Chris Wilson
Quoting Mika Kuoppala (2017-10-24 10:19:15)
> Chris Wilson  writes:
> 
> > Quoting Chris Wilson (2017-10-23 22:32:35)
> >> When we park the engine (upon idling), we kill the irq tasklet. However,
> >> to be sure that it is not restarted by a final interrupt after doing so,
> >> flush the interrupt handler before parking. As we only park the engines
> >> when we believe the system is idle, there should not be any spurious
> >> interrupts later to distrub us; so flushing the final in-flight
> >> interrupt should be sufficient.
> >> 
> >> Signed-off-by: Chris Wilson 
> >> Cc: Joonas Lahtinen 
> >> Cc: Mika Kuoppala 
> >> Cc: Imre Deak 
> >> ---
> >>  drivers/gpu/drm/i915/i915_gem.c | 6 ++
> >>  1 file changed, 6 insertions(+)
> >> 
> >> diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> >> b/drivers/gpu/drm/i915/i915_gem.c
> >> index bb0e85043e01..b547a6327d34 100644
> >> --- a/drivers/gpu/drm/i915/i915_gem.c
> >> +++ b/drivers/gpu/drm/i915/i915_gem.c
> >> @@ -3327,6 +3327,12 @@ i915_gem_idle_work_handler(struct work_struct *work)
> >> if (new_requests_since_last_retire(dev_priv))
> >> goto out_unlock;
> >>  
> >> +   /*
> >> +* Be paranoid and flush a concurrent interrupt to make sure
> >> +* we don't reactivate any irq tasklets after parking.
> >
> > * FIXME: Note that even though we have waited for execlists to be idle,
> > * there may still be an in-flight interrupt even though the CSB
> > * is now empty. synchronize_irq() makes sure that the residual
> > * interrupt is completed before we continue, but it doesn't prevent
> > * the HW from raising that residual interrupt later. To complete
> > * the shield we should coordinate disabling the CS irq with
> > * flushing the residual interrupt.
> 
> Apparently tasklet_kill is 'broken' in a sence that
> yeah new schedule reanimates the dead one. This
> seems weird guarantee for an api of such name and
> someone has even tried to fix it:
> 
> https://patchwork.kernel.org/patch/9298717/
> 
> I am pondering that can we combine the tasklet_disable
> into the mix. We would just defer the tasklet until
> we are ready and willing to process again?

Not for an extended period of time. tasklet_disable() has the
side-effect of spinning if a tasklet is scheduled between the
disable/enable calls. (It doesn't prevent the disabled tasklet from
being queued and doesn't remove it from the queue if it runs whilst
disabled.)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH i-g-t 1/6] meson: split out simple makefile integration into a makefile

2017-10-24 Thread Jani Nikula
A separate makefile is easier to read and maintain than a here
document. The meson.sh shell script becomes trivial too.

Signed-off-by: Jani Nikula 
---
 Makefile.meson | 33 +
 meson.sh   | 38 +++---
 2 files changed, 36 insertions(+), 35 deletions(-)
 create mode 100644 Makefile.meson

diff --git a/Makefile.meson b/Makefile.meson
new file mode 100644
index ..2ed642bdab37
--- /dev/null
+++ b/Makefile.meson
@@ -0,0 +1,33 @@
+# -*- makefile -*-
+# Simple makefile integration for meson
+
+.PHONY: default docs
+default: all
+
+Makefile: Makefile.meson
+   cp $< $@
+
+build/build.ninja: Makefile
+   mkdir -p build
+   meson build
+
+all: build/build.ninja
+   ninja -C build
+
+clean: build/build.ninja
+   ninja -C build clean
+
+test: build/build.ninja
+   ninja -C build test
+
+reconfigure: build/build.ninja
+   ninja -C build reconfigure
+
+check distcheck dist distclean:
+   echo "This is the meson wrapper, not automake" && false
+
+install uninstall:
+   echo "meson install support not yet completed" && false
+
+docs:
+   echo "meson gtkdoc support not yet completed" && false
diff --git a/meson.sh b/meson.sh
index cbf1a9326dbe..cdb384eb16a6 100755
--- a/meson.sh
+++ b/meson.sh
@@ -1,35 +1,3 @@
-#!/bin/bash
-
-cat > Makefile 

[Intel-gfx] [PATCH i-g-t 0/6] meson: makefile integration cleanup

2017-10-24 Thread Jani Nikula
I know the meson "makefile integration" is supposed to be just a simple
helper, but add a touch of polish to it anyway.

BR,
Jani.

Jani Nikula (6):
  meson: split out simple makefile integration into a makefile
  Makefile.meson: use $(error ...) for errors
  Makefile.meson: no need to mkdir build directory before running meson
  Makefile.meson: fix .PHONY deps
  Makefile.meson: no need to have a separate default target
  Makefile.meson: add distclean target to remove Makefile and build dir

 Makefile.meson | 35 +++
 meson.sh   | 38 +++---
 2 files changed, 38 insertions(+), 35 deletions(-)
 create mode 100644 Makefile.meson

-- 
2.11.0

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


[Intel-gfx] [PATCH i-g-t 2/6] Makefile.meson: use $(error ...) for errors

2017-10-24 Thread Jani Nikula
This is the usual way of flagging fatal errors in Makefiles, and gives
you the error exit code too.

Signed-off-by: Jani Nikula 
---
 Makefile.meson | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Makefile.meson b/Makefile.meson
index 2ed642bdab37..6955e6a9a694 100644
--- a/Makefile.meson
+++ b/Makefile.meson
@@ -24,10 +24,10 @@ reconfigure: build/build.ninja
ninja -C build reconfigure
 
 check distcheck dist distclean:
-   echo "This is the meson wrapper, not automake" && false
+   $(error This is the meson wrapper, not automake)
 
 install uninstall:
-   echo "meson install support not yet completed" && false
+   $(error meson install support not yet completed)
 
 docs:
-   echo "meson gtkdoc support not yet completed" && false
+   $(error meson gtkdoc support not yet completed)
-- 
2.11.0

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


[Intel-gfx] [PATCH i-g-t 3/6] Makefile.meson: no need to mkdir build directory before running meson

2017-10-24 Thread Jani Nikula
Meson creates the directory for you.

Signed-off-by: Jani Nikula 
---
 Makefile.meson | 1 -
 1 file changed, 1 deletion(-)

diff --git a/Makefile.meson b/Makefile.meson
index 6955e6a9a694..9f71cf341121 100644
--- a/Makefile.meson
+++ b/Makefile.meson
@@ -8,7 +8,6 @@ Makefile: Makefile.meson
cp $< $@
 
 build/build.ninja: Makefile
-   mkdir -p build
meson build
 
 all: build/build.ninja
-- 
2.11.0

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


[Intel-gfx] [PATCH v2 02/10] drm/i915: Start tracking voltage level in the cdclk state

2017-10-24 Thread Ville Syrjala
From: Ville Syrjälä 

For CNL we'll need to start considering the port clocks when we select
the voltage level for the system agent. To that end start tracking the
voltage in the cdclk state (since that already has to adjust it).

v2: s/voltage/voltage_level/ (Rodrigo)

Cc: Mika Kahola 
Cc: Manasi Navare 
Cc: Rodrigo Vivi 
Signed-off-by: Ville Syrjälä 
Reviewed-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/intel_cdclk.c  | 31 ---
 drivers/gpu/drm/i915/intel_display.c|  8 
 drivers/gpu/drm/i915/intel_drv.h|  4 +++-
 drivers/gpu/drm/i915/intel_runtime_pm.c |  3 ++-
 5 files changed, 34 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 54b5d4c582b6..2c64c6680ac7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2228,6 +2228,7 @@ struct i915_oa_ops {
 
 struct intel_cdclk_state {
unsigned int cdclk, vco, ref;
+   u8 voltage_level;
 };
 
 struct drm_i915_private {
diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
b/drivers/gpu/drm/i915/intel_cdclk.c
index 4bffd31a8924..6dad2efd5e27 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -1690,17 +1690,34 @@ void cnl_uninit_cdclk(struct drm_i915_private *dev_priv)
 }
 
 /**
- * intel_cdclk_state_compare - Determine if two CDCLK states differ
+ * intel_cdclk_needs_modeset - Determine if two CDCLK states require a modeset 
on all pipes
  * @a: first CDCLK state
  * @b: second CDCLK state
  *
  * Returns:
- * True if the CDCLK states are identical, false if they differ.
+ * True if the CDCLK states require pipes to be off during reprogramming, 
false if not.
  */
-bool intel_cdclk_state_compare(const struct intel_cdclk_state *a,
+bool intel_cdclk_needs_modeset(const struct intel_cdclk_state *a,
   const struct intel_cdclk_state *b)
 {
-   return memcmp(a, b, sizeof(*a)) == 0;
+   return a->cdclk != b->cdclk ||
+   a->vco != b->vco ||
+   a->ref != b->ref;
+}
+
+/**
+ * intel_cdclk_changed - Determine if two CDCLK states are different
+ * @a: first CDCLK state
+ * @b: second CDCLK state
+ *
+ * Returns:
+ * True if the CDCLK states don't match, false if they do.
+ */
+bool intel_cdclk_changed(const struct intel_cdclk_state *a,
+const struct intel_cdclk_state *b)
+{
+   return intel_cdclk_needs_modeset(a, b) ||
+   a->voltage_level != b->voltage_level;
 }
 
 /**
@@ -1714,15 +1731,15 @@ bool intel_cdclk_state_compare(const struct 
intel_cdclk_state *a,
 void intel_set_cdclk(struct drm_i915_private *dev_priv,
 const struct intel_cdclk_state *cdclk_state)
 {
-   if (intel_cdclk_state_compare(&dev_priv->cdclk.hw, cdclk_state))
+   if (!intel_cdclk_changed(&dev_priv->cdclk.hw, cdclk_state))
return;
 
if (WARN_ON_ONCE(!dev_priv->display.set_cdclk))
return;
 
-   DRM_DEBUG_DRIVER("Changing CDCLK to %d kHz, VCO %d kHz, ref %d kHz\n",
+   DRM_DEBUG_DRIVER("Changing CDCLK to %d kHz, VCO %d kHz, ref %d kHz, 
voltage_level %d\n",
 cdclk_state->cdclk, cdclk_state->vco,
-cdclk_state->ref);
+cdclk_state->ref, cdclk_state->voltage_level);
 
dev_priv->display.set_cdclk(dev_priv, cdclk_state);
 }
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index e2ac976844d8..1d2031a5f4bb 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11931,16 +11931,16 @@ static int intel_modeset_checks(struct 
drm_atomic_state *state)
 * holding all the crtc locks, even if we don't end up
 * touching the hardware
 */
-   if (!intel_cdclk_state_compare(&dev_priv->cdclk.logical,
-  &intel_state->cdclk.logical)) {
+   if (intel_cdclk_changed(&dev_priv->cdclk.logical,
+   &intel_state->cdclk.logical)) {
ret = intel_lock_all_pipes(state);
if (ret < 0)
return ret;
}
 
/* All pipes must be switched off while we change the cdclk. */
-   if (!intel_cdclk_state_compare(&dev_priv->cdclk.actual,
-  &intel_state->cdclk.actual)) {
+   if (intel_cdclk_needs_modeset(&dev_priv->cdclk.actual,
+ &intel_state->cdclk.actual)) {
ret = intel_modeset_all_pipes(state);
if (ret < 0)
return ret;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 47d022d48718..a551aadb157

[Intel-gfx] [PATCH v4 03/10] drm/i915: Use cdclk_state->voltage on VLV/CHV

2017-10-24 Thread Ville Syrjala
From: Ville Syrjälä 

Store the punit DSPFREQUAR value into cdclk_state->voltage on
VLV/CHV. Since we can actually read that out from the hardware
this can give us a bit more cross checking between the hardware
and software state.

v2: Don't break waiting for cdclk change on VLV/CHV
v3: Split out the cdclk sanity check in vlv_set_cdclk() (Rodrigo)
v4: s/voltage/voltage_level/ (Rodrigo)

Cc: Mika Kahola 
Cc: Manasi Navare 
Cc: Rodrigo Vivi 
Signed-off-by: Ville Syrjälä 
Reviewed-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_cdclk.c | 54 +++---
 1 file changed, 38 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
b/drivers/gpu/drm/i915/intel_cdclk.c
index 6dad2efd5e27..8bc093082511 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -437,13 +437,45 @@ static int vlv_calc_cdclk(struct drm_i915_private 
*dev_priv, int min_cdclk)
return 20;
 }
 
+static u8 vlv_calc_voltage_level(struct drm_i915_private *dev_priv, int cdclk)
+{
+   if (IS_VALLEYVIEW(dev_priv)) {
+   if (cdclk >= 32) /* jump to highest voltage for 400MHz too 
*/
+   return 2;
+   else if (cdclk >= 27)
+   return 1;
+   else
+   return 0;
+   } else {
+   /*
+* Specs are full of misinformation, but testing on actual
+* hardware has shown that we just need to write the desired
+* CCK divider into the Punit register.
+*/
+   return DIV_ROUND_CLOSEST(dev_priv->hpll_freq << 1, cdclk) - 1;
+   }
+}
+
 static void vlv_get_cdclk(struct drm_i915_private *dev_priv,
  struct intel_cdclk_state *cdclk_state)
 {
+   u32 val;
+
cdclk_state->vco = vlv_get_hpll_vco(dev_priv);
cdclk_state->cdclk = vlv_get_cck_clock(dev_priv, "cdclk",
   CCK_DISPLAY_CLOCK_CONTROL,
   cdclk_state->vco);
+
+   mutex_lock(&dev_priv->pcu_lock);
+   val = vlv_punit_read(dev_priv, PUNIT_REG_DSPFREQ);
+   mutex_unlock(&dev_priv->pcu_lock);
+
+   if (IS_VALLEYVIEW(dev_priv))
+   cdclk_state->voltage_level = (val & DSPFREQGUAR_MASK) >>
+   DSPFREQGUAR_SHIFT;
+   else
+   cdclk_state->voltage_level = (val & DSPFREQGUAR_MASK_CHV) >>
+   DSPFREQGUAR_SHIFT_CHV;
 }
 
 static void vlv_program_pfi_credits(struct drm_i915_private *dev_priv)
@@ -486,7 +518,7 @@ static void vlv_set_cdclk(struct drm_i915_private *dev_priv,
  const struct intel_cdclk_state *cdclk_state)
 {
int cdclk = cdclk_state->cdclk;
-   u32 val, cmd;
+   u32 val, cmd = cdclk_state->voltage_level;
 
/* There are cases where we can end up here with power domains
 * off and a CDCLK frequency other than the minimum, like when
@@ -496,13 +528,6 @@ static void vlv_set_cdclk(struct drm_i915_private 
*dev_priv,
 */
intel_display_power_get(dev_priv, POWER_DOMAIN_PIPE_A);
 
-   if (cdclk >= 32) /* jump to highest voltage for 400MHz too */
-   cmd = 2;
-   else if (cdclk == 27)
-   cmd = 1;
-   else
-   cmd = 0;
-
mutex_lock(&dev_priv->pcu_lock);
val = vlv_punit_read(dev_priv, PUNIT_REG_DSPFREQ);
val &= ~DSPFREQGUAR_MASK;
@@ -562,7 +587,7 @@ static void chv_set_cdclk(struct drm_i915_private *dev_priv,
  const struct intel_cdclk_state *cdclk_state)
 {
int cdclk = cdclk_state->cdclk;
-   u32 val, cmd;
+   u32 val, cmd = cdclk_state->voltage_level;
 
switch (cdclk) {
case 33:
@@ -583,13 +608,6 @@ static void chv_set_cdclk(struct drm_i915_private 
*dev_priv,
 */
intel_display_power_get(dev_priv, POWER_DOMAIN_PIPE_A);
 
-   /*
-* Specs are full of misinformation, but testing on actual
-* hardware has shown that we just need to write the desired
-* CCK divider into the Punit register.
-*/
-   cmd = DIV_ROUND_CLOSEST(dev_priv->hpll_freq << 1, cdclk) - 1;
-
mutex_lock(&dev_priv->pcu_lock);
val = vlv_punit_read(dev_priv, PUNIT_REG_DSPFREQ);
val &= ~DSPFREQGUAR_MASK_CHV;
@@ -1859,11 +1877,15 @@ static int vlv_modeset_calc_cdclk(struct 
drm_atomic_state *state)
cdclk = vlv_calc_cdclk(dev_priv, min_cdclk);
 
intel_state->cdclk.logical.cdclk = cdclk;
+   intel_state->cdclk.logical.voltage_level =
+   vlv_calc_voltage_level(dev_priv, cdclk);
 
if (!intel_state->active_crtcs) {
cdclk = vlv_calc_cdclk(dev_priv, 0);
 
intel_state->cdclk.actual.cdclk = cdclk;
+   intel_state->cdclk.actual.voltage_level =
+   vlv_calc_voltage_level(dev

[Intel-gfx] [PATCH i-g-t 4/6] Makefile.meson: fix .PHONY deps

2017-10-24 Thread Jani Nikula
Most targets here are phony, tell that to make. Avoid potentials
collisions with files and directories with the same names.

Signed-off-by: Jani Nikula 
---
 Makefile.meson | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Makefile.meson b/Makefile.meson
index 9f71cf341121..82fa50bf92e5 100644
--- a/Makefile.meson
+++ b/Makefile.meson
@@ -1,7 +1,9 @@
 # -*- makefile -*-
 # Simple makefile integration for meson
 
-.PHONY: default docs
+.PHONY: default all clean test reconfigure check distcheck dist distclean \
+   install uninstall docs
+
 default: all
 
 Makefile: Makefile.meson
-- 
2.11.0

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


[Intel-gfx] [PATCH 01/10] drm/i915: Clean up some cdclk switch statements

2017-10-24 Thread Ville Syrjala
From: Ville Syrjälä 

Redo some switch statements in the cdclk code to use a common
fall through for the default case. Makes everything look a bit
more uniform

Cc: Mika Kahola 
Cc: Manasi Navare 
Cc: Rodrigo Vivi 
Signed-off-by: Ville Syrjälä 
Reviewed-by: Mika Kahola 
---
 drivers/gpu/drm/i915/intel_cdclk.c | 68 +++---
 1 file changed, 34 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
b/drivers/gpu/drm/i915/intel_cdclk.c
index b2a6d62b71c0..4bffd31a8924 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -681,6 +681,13 @@ static void bdw_set_cdclk(struct drm_i915_private 
*dev_priv,
val &= ~LCPLL_CLK_FREQ_MASK;
 
switch (cdclk) {
+   default:
+   MISSING_CASE(cdclk);
+   /* fall through */
+   case 337500:
+   val |= LCPLL_CLK_FREQ_337_5_BDW;
+   data = 2;
+   break;
case 45:
val |= LCPLL_CLK_FREQ_450;
data = 0;
@@ -689,17 +696,10 @@ static void bdw_set_cdclk(struct drm_i915_private 
*dev_priv,
val |= LCPLL_CLK_FREQ_54O_BDW;
data = 1;
break;
-   case 337500:
-   val |= LCPLL_CLK_FREQ_337_5_BDW;
-   data = 2;
-   break;
case 675000:
val |= LCPLL_CLK_FREQ_675_BDW;
data = 3;
break;
-   default:
-   WARN(1, "invalid cdclk frequency\n");
-   return;
}
 
I915_WRITE(LCPLL_CTL, val);
@@ -926,8 +926,6 @@ static void skl_set_cdclk(struct drm_i915_private *dev_priv,
u32 freq_select, pcu_ack;
int ret;
 
-   WARN_ON((cdclk == 24000) != (vco == 0));
-
mutex_lock(&dev_priv->pcu_lock);
ret = skl_pcode_request(dev_priv, SKL_PCODE_CDCLK_CONTROL,
SKL_CDCLK_PREPARE_FOR_CHANGE,
@@ -942,6 +940,15 @@ static void skl_set_cdclk(struct drm_i915_private 
*dev_priv,
 
/* set CDCLK_CTL */
switch (cdclk) {
+   default:
+   WARN_ON(cdclk != dev_priv->cdclk.hw.ref);
+   WARN_ON(vco != 0);
+   /* fall through */
+   case 308571:
+   case 337500:
+   freq_select = CDCLK_FREQ_337_308;
+   pcu_ack = 0;
+   break;
case 45:
case 432000:
freq_select = CDCLK_FREQ_450_432;
@@ -951,12 +958,6 @@ static void skl_set_cdclk(struct drm_i915_private 
*dev_priv,
freq_select = CDCLK_FREQ_540;
pcu_ack = 2;
break;
-   case 308571:
-   case 337500:
-   default:
-   freq_select = CDCLK_FREQ_337_308;
-   pcu_ack = 0;
-   break;
case 617143:
case 675000:
freq_select = CDCLK_FREQ_675_617;
@@ -1110,6 +,7 @@ static int bxt_de_pll_vco(struct drm_i915_private 
*dev_priv, int cdclk)
switch (cdclk) {
default:
MISSING_CASE(cdclk);
+   /* fall through */
case 144000:
case 288000:
case 384000:
@@ -1134,6 +1136,7 @@ static int glk_de_pll_vco(struct drm_i915_private 
*dev_priv, int cdclk)
switch (cdclk) {
default:
MISSING_CASE(cdclk);
+   /* fall through */
case  79200:
case 158400:
case 316800:
@@ -1246,24 +1249,22 @@ static void bxt_set_cdclk(struct drm_i915_private 
*dev_priv,
 
/* cdclk = vco / 2 / div{1,1.5,2,4} */
switch (DIV_ROUND_CLOSEST(vco, cdclk)) {
-   case 8:
-   divider = BXT_CDCLK_CD2X_DIV_SEL_4;
-   break;
-   case 4:
-   divider = BXT_CDCLK_CD2X_DIV_SEL_2;
+   default:
+   WARN_ON(cdclk != dev_priv->cdclk.hw.ref);
+   WARN_ON(vco != 0);
+   /* fall through */
+   case 2:
+   divider = BXT_CDCLK_CD2X_DIV_SEL_1;
break;
case 3:
WARN(IS_GEMINILAKE(dev_priv), "Unsupported divider\n");
divider = BXT_CDCLK_CD2X_DIV_SEL_1_5;
break;
-   case 2:
-   divider = BXT_CDCLK_CD2X_DIV_SEL_1;
+   case 4:
+   divider = BXT_CDCLK_CD2X_DIV_SEL_2;
break;
-   default:
-   WARN_ON(cdclk != dev_priv->cdclk.hw.ref);
-   WARN_ON(vco != 0);
-
-   divider = BXT_CDCLK_CD2X_DIV_SEL_1;
+   case 8:
+   divider = BXT_CDCLK_CD2X_DIV_SEL_4;
break;
}
 
@@ -1532,18 +1533,16 @@ static void cnl_set_cdclk(struct drm_i915_private 
*dev_priv,
 
/* cdclk = vco / 2 / div{1,2} */
switch (DIV_ROUND_CLOSEST(vco, cdclk)) {
-   case 4:
-   divider = BXT_CDCLK_CD2X_DIV_SEL_2;
-   break;
-   case 2:
-   divider = BXT_CDCLK_CD2X_DIV_SEL_1;
-   break

[Intel-gfx] [PATCH v3 04/10] drm/i915: Use cdclk_state->voltage on BDW

2017-10-24 Thread Ville Syrjala
From: Ville Syrjälä 

Track the system agent voltage we request from pcode in the cdclk state
on BDW. Annoyingly we can't actually read out the current value since
there's no pcode command to do that, so we'll have to just assume that
it worked.

v2: Keep the WARN_ON (Rodrigo)
v3: s/voltage/voltage_level/ (Rodrigo)

Cc: Mika Kahola 
Cc: Manasi Navare 
Cc: Rodrigo Vivi 
Signed-off-by: Ville Syrjälä 
Reviewed-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_cdclk.c | 35 +--
 1 file changed, 29 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
b/drivers/gpu/drm/i915/intel_cdclk.c
index 8bc093082511..c98fec333dd1 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -639,6 +639,21 @@ static int bdw_calc_cdclk(int min_cdclk)
return 337500;
 }
 
+static u8 bdw_calc_voltage_level(int cdclk)
+{
+   switch (cdclk) {
+   default:
+   case 337500:
+   return 2;
+   case 45:
+   return 0;
+   case 54:
+   return 1;
+   case 675000:
+   return 3;
+   }
+}
+
 static void bdw_get_cdclk(struct drm_i915_private *dev_priv,
  struct intel_cdclk_state *cdclk_state)
 {
@@ -657,13 +672,20 @@ static void bdw_get_cdclk(struct drm_i915_private 
*dev_priv,
cdclk_state->cdclk = 337500;
else
cdclk_state->cdclk = 675000;
+
+   /*
+* Can't read this out :( Let's assume it's
+* at least what the CDCLK frequency requires.
+*/
+   cdclk_state->voltage_level =
+   bdw_calc_voltage_level(cdclk_state->cdclk);
 }
 
 static void bdw_set_cdclk(struct drm_i915_private *dev_priv,
  const struct intel_cdclk_state *cdclk_state)
 {
int cdclk = cdclk_state->cdclk;
-   uint32_t val, data;
+   uint32_t val;
int ret;
 
if (WARN((I915_READ(LCPLL_CTL) &
@@ -704,19 +726,15 @@ static void bdw_set_cdclk(struct drm_i915_private 
*dev_priv,
/* fall through */
case 337500:
val |= LCPLL_CLK_FREQ_337_5_BDW;
-   data = 2;
break;
case 45:
val |= LCPLL_CLK_FREQ_450;
-   data = 0;
break;
case 54:
val |= LCPLL_CLK_FREQ_54O_BDW;
-   data = 1;
break;
case 675000:
val |= LCPLL_CLK_FREQ_675_BDW;
-   data = 3;
break;
}
 
@@ -731,7 +749,8 @@ static void bdw_set_cdclk(struct drm_i915_private *dev_priv,
DRM_ERROR("Switching back to LCPLL failed\n");
 
mutex_lock(&dev_priv->pcu_lock);
-   sandybridge_pcode_write(dev_priv, HSW_PCODE_DE_WRITE_FREQ_REQ, data);
+   sandybridge_pcode_write(dev_priv, HSW_PCODE_DE_WRITE_FREQ_REQ,
+   cdclk_state->voltage_level);
mutex_unlock(&dev_priv->pcu_lock);
 
I915_WRITE(CDCLK_FREQ, DIV_ROUND_CLOSEST(cdclk, 1000) - 1);
@@ -1910,11 +1929,15 @@ static int bdw_modeset_calc_cdclk(struct 
drm_atomic_state *state)
cdclk = bdw_calc_cdclk(min_cdclk);
 
intel_state->cdclk.logical.cdclk = cdclk;
+   intel_state->cdclk.logical.voltage_level =
+   bdw_calc_voltage_level(cdclk);
 
if (!intel_state->active_crtcs) {
cdclk = bdw_calc_cdclk(0);
 
intel_state->cdclk.actual.cdclk = cdclk;
+   intel_state->cdclk.actual.voltage_level =
+   bdw_calc_voltage_level(cdclk);
} else {
intel_state->cdclk.actual =
intel_state->cdclk.logical;
-- 
2.13.6

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


[Intel-gfx] [PATCH v2 06/10] drm/i915: Use cdclk_state->voltage on BXT/GLK

2017-10-24 Thread Ville Syrjala
From: Ville Syrjälä 

Track the system agent voltage we request from pcode in the cdclk state
on BXT/GLK. Annoyingly we can't actually read out the current value since
there's no pcode command to do that, so we'll have to just assume that
it worked.

v2: s/voltage/voltage_level/ (Rodrigo)

Cc: Mika Kahola 
Cc: Manasi Navare 
Cc: Rodrigo Vivi 
Signed-off-by: Ville Syrjälä 
Reviewed-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_cdclk.c | 23 +--
 1 file changed, 21 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
b/drivers/gpu/drm/i915/intel_cdclk.c
index 38e31df265bd..a40dc66dc773 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -1163,6 +1163,11 @@ static int glk_calc_cdclk(int min_cdclk)
return 79200;
 }
 
+static u8 bxt_calc_voltage_level(int cdclk)
+{
+   return DIV_ROUND_UP(cdclk, 25000);
+}
+
 static int bxt_de_pll_vco(struct drm_i915_private *dev_priv, int cdclk)
 {
int ratio;
@@ -1239,7 +1244,7 @@ static void bxt_get_cdclk(struct drm_i915_private 
*dev_priv,
cdclk_state->cdclk = cdclk_state->ref;
 
if (cdclk_state->vco == 0)
-   return;
+   goto out;
 
divider = I915_READ(CDCLK_CTL) & BXT_CDCLK_CD2X_DIV_SEL_MASK;
 
@@ -1263,6 +1268,14 @@ static void bxt_get_cdclk(struct drm_i915_private 
*dev_priv,
}
 
cdclk_state->cdclk = DIV_ROUND_CLOSEST(cdclk_state->vco, div);
+
+ out:
+   /*
+* Can't read this out :( Let's assume it's
+* at least what the CDCLK frequency requires.
+*/
+   cdclk_state->voltage_level =
+   bxt_calc_voltage_level(cdclk_state->cdclk);
 }
 
 static void bxt_de_pll_disable(struct drm_i915_private *dev_priv)
@@ -1365,7 +1378,7 @@ static void bxt_set_cdclk(struct drm_i915_private 
*dev_priv,
 
mutex_lock(&dev_priv->pcu_lock);
ret = sandybridge_pcode_write(dev_priv, HSW_PCODE_DE_WRITE_FREQ_REQ,
- DIV_ROUND_UP(cdclk, 25000));
+ cdclk_state->voltage_level);
mutex_unlock(&dev_priv->pcu_lock);
 
if (ret) {
@@ -1457,6 +1470,7 @@ void bxt_init_cdclk(struct drm_i915_private *dev_priv)
cdclk_state.cdclk = bxt_calc_cdclk(0);
cdclk_state.vco = bxt_de_pll_vco(dev_priv, cdclk_state.cdclk);
}
+   cdclk_state.voltage_level = bxt_calc_voltage_level(cdclk_state.cdclk);
 
bxt_set_cdclk(dev_priv, &cdclk_state);
 }
@@ -1474,6 +1488,7 @@ void bxt_uninit_cdclk(struct drm_i915_private *dev_priv)
 
cdclk_state.cdclk = cdclk_state.ref;
cdclk_state.vco = 0;
+   cdclk_state.voltage_level = bxt_calc_voltage_level(cdclk_state.cdclk);
 
bxt_set_cdclk(dev_priv, &cdclk_state);
 }
@@ -2031,6 +2046,8 @@ static int bxt_modeset_calc_cdclk(struct drm_atomic_state 
*state)
 
intel_state->cdclk.logical.vco = vco;
intel_state->cdclk.logical.cdclk = cdclk;
+   intel_state->cdclk.logical.voltage_level =
+   bxt_calc_voltage_level(cdclk);
 
if (!intel_state->active_crtcs) {
if (IS_GEMINILAKE(dev_priv)) {
@@ -2043,6 +2060,8 @@ static int bxt_modeset_calc_cdclk(struct drm_atomic_state 
*state)
 
intel_state->cdclk.actual.vco = vco;
intel_state->cdclk.actual.cdclk = cdclk;
+   intel_state->cdclk.actual.voltage_level =
+   bxt_calc_voltage_level(cdclk);
} else {
intel_state->cdclk.actual =
intel_state->cdclk.logical;
-- 
2.13.6

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


[Intel-gfx] [PATCH i-g-t 6/6] Makefile.meson: add distclean target to remove Makefile and build dir

2017-10-24 Thread Jani Nikula
Useful for forcing a clean meson build from scratch.

Signed-off-by: Jani Nikula 
---
 Makefile.meson | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Makefile.meson b/Makefile.meson
index c7a87f37f47d..2e09c11052da 100644
--- a/Makefile.meson
+++ b/Makefile.meson
@@ -16,13 +16,16 @@ build/build.ninja: Makefile
 clean: build/build.ninja
ninja -C build clean
 
+distclean:
+   rm -rf build Makefile
+
 test: build/build.ninja
ninja -C build test
 
 reconfigure: build/build.ninja
ninja -C build reconfigure
 
-check distcheck dist distclean:
+check distcheck dist:
$(error This is the meson wrapper, not automake)
 
 install uninstall:
-- 
2.11.0

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


[Intel-gfx] [PATCH i-g-t 5/6] Makefile.meson: no need to have a separate default target

2017-10-24 Thread Jani Nikula
Just place "all" target at the top. Makefiles aren't ordered.

Signed-off-by: Jani Nikula 
---
 Makefile.meson | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/Makefile.meson b/Makefile.meson
index 82fa50bf92e5..c7a87f37f47d 100644
--- a/Makefile.meson
+++ b/Makefile.meson
@@ -1,10 +1,11 @@
 # -*- makefile -*-
 # Simple makefile integration for meson
 
-.PHONY: default all clean test reconfigure check distcheck dist distclean \
-   install uninstall docs
+.PHONY: all clean test reconfigure check distcheck dist distclean install \
+   uninstall docs
 
-default: all
+all: build/build.ninja
+   ninja -C build
 
 Makefile: Makefile.meson
cp $< $@
@@ -12,9 +13,6 @@ Makefile: Makefile.meson
 build/build.ninja: Makefile
meson build
 
-all: build/build.ninja
-   ninja -C build
-
 clean: build/build.ninja
ninja -C build clean
 
-- 
2.11.0

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


[Intel-gfx] [PATCH v2 00/10] drm/i915: CNL DVFS thing

2017-10-24 Thread Ville Syrjala
From: Ville Syrjälä 

New version of the CNL DVFS series. Everything from the previous series
(first 8 patches) are already reviewed. I slapped on two additional patches
that fell out from the review of the first series.

Entire series available here:
git://github.com/vsyrjala/linux.git dvfs_voltage_6

Ville Syrjälä (10):
  drm/i915: Clean up some cdclk switch statements
  drm/i915: Start tracking voltage level in the cdclk state
  drm/i915: Use cdclk_state->voltage on VLV/CHV
  drm/i915: Use cdclk_state->voltage on BDW
  drm/i915: Use cdclk_state->voltage on SKL/KBL/CFL
  drm/i915: Use cdclk_state->voltage on BXT/GLK
  drm/i915: Use cdclk_state->voltage on CNL
  drm/i915: Adjust system agent voltage on CNL if required by DDI ports
  drm/i915: Sanity check cdclk in vlv_set_cdclk()
  drm/i915: Perform a central cdclk state sanity check

 drivers/gpu/drm/i915/i915_drv.h |   3 +
 drivers/gpu/drm/i915/intel_cdclk.c  | 377 
 drivers/gpu/drm/i915/intel_ddi.c|  11 +
 drivers/gpu/drm/i915/intel_display.c|  22 +-
 drivers/gpu/drm/i915/intel_dp_mst.c |   5 +
 drivers/gpu/drm/i915/intel_dpll_mgr.c   |  16 +-
 drivers/gpu/drm/i915/intel_drv.h|  13 +-
 drivers/gpu/drm/i915/intel_runtime_pm.c |   3 +-
 8 files changed, 342 insertions(+), 108 deletions(-)

-- 
2.13.6

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


[Intel-gfx] [PATCH 09/10] drm/i915: Sanity check cdclk in vlv_set_cdclk()

2017-10-24 Thread Ville Syrjala
From: Ville Syrjälä 

chv_set_cdclk() sanity checks that the cdclk frequency is one of the
legal values. Do the same in the VLV function.

Cc: Mika Kahola 
Cc: Manasi Navare 
Cc: Rodrigo Vivi 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_cdclk.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
b/drivers/gpu/drm/i915/intel_cdclk.c
index 4ca4a34b7bfa..fedfe3c720b6 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -520,6 +520,18 @@ static void vlv_set_cdclk(struct drm_i915_private 
*dev_priv,
int cdclk = cdclk_state->cdclk;
u32 val, cmd = cdclk_state->voltage_level;
 
+   switch (cdclk) {
+   case 40:
+   case 33:
+   case 32:
+   case 27:
+   case 20:
+   break;
+   default:
+   MISSING_CASE(cdclk);
+   return;
+   }
+
/* There are cases where we can end up here with power domains
 * off and a CDCLK frequency other than the minimum, like when
 * issuing a modeset without actually changing any display after
-- 
2.13.6

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


[Intel-gfx] [PATCH v2 07/10] drm/i915: Use cdclk_state->voltage on CNL

2017-10-24 Thread Ville Syrjala
From: Ville Syrjälä 

Track the system agent voltage we request from pcode in the cdclk state
on CNL. Annoyingly we can't actually read out the current value since
there's no pcode command to do that, so we'll have to just assume that
it worked.

v2: s/voltage/voltage_level/ (Rodrigo)

Cc: Mika Kahola 
Cc: Manasi Navare 
Cc: Rodrigo Vivi 
Signed-off-by: Ville Syrjälä 
Reviewed-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_cdclk.c | 47 +-
 1 file changed, 31 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
b/drivers/gpu/drm/i915/intel_cdclk.c
index a40dc66dc773..210e79193fe6 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -1503,6 +1503,19 @@ static int cnl_calc_cdclk(int min_cdclk)
return 168000;
 }
 
+static u8 cnl_calc_voltage_level(int cdclk)
+{
+   switch (cdclk) {
+   default:
+   case 168000:
+   return 0;
+   case 336000:
+   return 1;
+   case 528000:
+   return 2;
+   }
+}
+
 static void cnl_cdclk_pll_update(struct drm_i915_private *dev_priv,
 struct intel_cdclk_state *cdclk_state)
 {
@@ -1536,7 +1549,7 @@ static void cnl_get_cdclk(struct drm_i915_private 
*dev_priv,
cdclk_state->cdclk = cdclk_state->ref;
 
if (cdclk_state->vco == 0)
-   return;
+   goto out;
 
divider = I915_READ(CDCLK_CTL) & BXT_CDCLK_CD2X_DIV_SEL_MASK;
 
@@ -1553,6 +1566,14 @@ static void cnl_get_cdclk(struct drm_i915_private 
*dev_priv,
}
 
cdclk_state->cdclk = DIV_ROUND_CLOSEST(cdclk_state->vco, div);
+
+ out:
+   /*
+* Can't read this out :( Let's assume it's
+* at least what the CDCLK frequency requires.
+*/
+   cdclk_state->voltage_level =
+   cnl_calc_voltage_level(cdclk_state->cdclk);
 }
 
 static void cnl_cdclk_pll_disable(struct drm_i915_private *dev_priv)
@@ -1593,7 +1614,7 @@ static void cnl_set_cdclk(struct drm_i915_private 
*dev_priv,
 {
int cdclk = cdclk_state->cdclk;
int vco = cdclk_state->vco;
-   u32 val, divider, pcu_ack;
+   u32 val, divider;
int ret;
 
mutex_lock(&dev_priv->pcu_lock);
@@ -1622,19 +1643,6 @@ static void cnl_set_cdclk(struct drm_i915_private 
*dev_priv,
break;
}
 
-   switch (cdclk) {
-   case 528000:
-   pcu_ack = 2;
-   break;
-   case 336000:
-   pcu_ack = 1;
-   break;
-   case 168000:
-   default:
-   pcu_ack = 0;
-   break;
-   }
-
if (dev_priv->cdclk.hw.vco != 0 &&
dev_priv->cdclk.hw.vco != vco)
cnl_cdclk_pll_disable(dev_priv);
@@ -1652,7 +1660,8 @@ static void cnl_set_cdclk(struct drm_i915_private 
*dev_priv,
 
/* inform PCU of the change */
mutex_lock(&dev_priv->pcu_lock);
-   sandybridge_pcode_write(dev_priv, SKL_PCODE_CDCLK_CONTROL, pcu_ack);
+   sandybridge_pcode_write(dev_priv, SKL_PCODE_CDCLK_CONTROL,
+   cdclk_state->voltage_level);
mutex_unlock(&dev_priv->pcu_lock);
 
intel_update_cdclk(dev_priv);
@@ -1745,6 +1754,7 @@ void cnl_init_cdclk(struct drm_i915_private *dev_priv)
 
cdclk_state.cdclk = cnl_calc_cdclk(0);
cdclk_state.vco = cnl_cdclk_pll_vco(dev_priv, cdclk_state.cdclk);
+   cdclk_state.voltage_level = cnl_calc_voltage_level(cdclk_state.cdclk);
 
cnl_set_cdclk(dev_priv, &cdclk_state);
 }
@@ -1762,6 +1772,7 @@ void cnl_uninit_cdclk(struct drm_i915_private *dev_priv)
 
cdclk_state.cdclk = cdclk_state.ref;
cdclk_state.vco = 0;
+   cdclk_state.voltage_level = cnl_calc_voltage_level(cdclk_state.cdclk);
 
cnl_set_cdclk(dev_priv, &cdclk_state);
 }
@@ -2085,6 +2096,8 @@ static int cnl_modeset_calc_cdclk(struct drm_atomic_state 
*state)
 
intel_state->cdclk.logical.vco = vco;
intel_state->cdclk.logical.cdclk = cdclk;
+   intel_state->cdclk.logical.voltage_level =
+   cnl_calc_voltage_level(cdclk);
 
if (!intel_state->active_crtcs) {
cdclk = cnl_calc_cdclk(0);
@@ -2092,6 +2105,8 @@ static int cnl_modeset_calc_cdclk(struct drm_atomic_state 
*state)
 
intel_state->cdclk.actual.vco = vco;
intel_state->cdclk.actual.cdclk = cdclk;
+   intel_state->cdclk.actual.voltage_level =
+   cnl_calc_voltage_level(cdclk);
} else {
intel_state->cdclk.actual =
intel_state->cdclk.logical;
-- 
2.13.6

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


[Intel-gfx] [PATCH v4 08/10] drm/i915: Adjust system agent voltage on CNL if required by DDI ports

2017-10-24 Thread Ville Syrjala
From: Ville Syrjälä 

On CNL we may need to bump up the system agent voltage not only due
to CDCLK but also when driving DDI port with a sufficiently high clock.
To that end start tracking the minimum acceptable voltage for each crtc.
We do the tracking via crtcs because we don't have any kind of encoder
state. Also there's no downside to doing it this way, and it matches how
we track cdclk requirements on account of pixel rate.

v2: Allow disabled crtcs to use the min voltage
Add IS_CNL check to intel_ddi_compute_min_voltage() since
we're using CNL specific values there
s/intel_compute_min_voltage/cnl_compute_min_voltage/ since
the function makes hw specific assumptions about the voltage
values
v3: Drop the test hack leftovers from skl_modeset_calc_cdclk()
v4: s/voltage/voltage_level/ (Rodrigo)
Replace DPLL DVFS FIXMEs with an explanation why we don't
do anything there (Rodrigo)

Cc: Mika Kahola 
Cc: Manasi Navare 
Cc: Rodrigo Vivi 
Signed-off-by: Ville Syrjälä 
Reviewed-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_drv.h   |  2 ++
 drivers/gpu/drm/i915/intel_cdclk.c| 46 ++-
 drivers/gpu/drm/i915/intel_ddi.c  | 11 +
 drivers/gpu/drm/i915/intel_display.c  | 11 +
 drivers/gpu/drm/i915/intel_dp_mst.c   |  5 
 drivers/gpu/drm/i915/intel_dpll_mgr.c | 16 ++--
 drivers/gpu/drm/i915/intel_drv.h  |  7 ++
 7 files changed, 89 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2c64c6680ac7..366ba74b0ad2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2416,6 +2416,8 @@ struct drm_i915_private {
unsigned int active_crtcs;
/* minimum acceptable cdclk for each pipe */
int min_cdclk[I915_MAX_PIPES];
+   /* minimum acceptable voltage level for each pipe */
+   u8 min_voltage_level[I915_MAX_PIPES];
 
int dpio_phy_iosf_port[I915_NUM_PHYS_VLV];
 
diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
b/drivers/gpu/drm/i915/intel_cdclk.c
index 210e79193fe6..4ca4a34b7bfa 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -1665,6 +1665,12 @@ static void cnl_set_cdclk(struct drm_i915_private 
*dev_priv,
mutex_unlock(&dev_priv->pcu_lock);
 
intel_update_cdclk(dev_priv);
+
+   /*
+* Can't read out the voltage level :(
+* Let's just assume everything is as expected.
+*/
+   dev_priv->cdclk.hw.voltage_level = cdclk_state->voltage_level;
 }
 
 static int cnl_cdclk_pll_vco(struct drm_i915_private *dev_priv, int cdclk)
@@ -1934,6 +1940,43 @@ static int intel_compute_min_cdclk(struct 
drm_atomic_state *state)
return min_cdclk;
 }
 
+/*
+ * Note that this functions assumes that 0 is
+ * the lowest voltage value, and higher values
+ * correspond to increasingly higher voltages.
+ *
+ * Should that relationship no longer hold on
+ * future platforms this code will need to be
+ * adjusted.
+ */
+static u8 cnl_compute_min_voltage_level(struct intel_atomic_state *state)
+{
+   struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+   struct intel_crtc *crtc;
+   struct intel_crtc_state *crtc_state;
+   u8 min_voltage_level;
+   int i;
+   enum pipe pipe;
+
+   memcpy(state->min_voltage_level, dev_priv->min_voltage_level,
+  sizeof(state->min_voltage_level));
+
+   for_each_new_intel_crtc_in_state(state, crtc, crtc_state, i) {
+   if (crtc_state->base.enable)
+   state->min_voltage_level[i] =
+   crtc_state->min_voltage_level;
+   else
+   state->min_voltage_level[i] = 0;
+   }
+
+   min_voltage_level = 0;
+   for_each_pipe(dev_priv, pipe)
+   min_voltage_level = max(state->min_voltage_level[pipe],
+   min_voltage_level);
+
+   return min_voltage_level;
+}
+
 static int vlv_modeset_calc_cdclk(struct drm_atomic_state *state)
 {
struct drm_i915_private *dev_priv = to_i915(state->dev);
@@ -2097,7 +2140,8 @@ static int cnl_modeset_calc_cdclk(struct drm_atomic_state 
*state)
intel_state->cdclk.logical.vco = vco;
intel_state->cdclk.logical.cdclk = cdclk;
intel_state->cdclk.logical.voltage_level =
-   cnl_calc_voltage_level(cdclk);
+   max(cnl_calc_voltage_level(cdclk),
+   cnl_compute_min_voltage_level(intel_state));
 
if (!intel_state->active_crtcs) {
cdclk = cnl_calc_cdclk(0);
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 933c18fd4258..4c02930363a8 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2542,6 +2542,13 @@ bool intel_ddi_is_audio_enabled(struct drm_i915_private 
*dev_priv,
return false;
 }
 
+void intel_ddi_comput

[Intel-gfx] [PATCH 10/10] drm/i915: Perform a central cdclk state sanity check

2017-10-24 Thread Ville Syrjala
From: Ville Syrjälä 

WARN if the cdclk state doesn't match what we expect after programming.
And let's remove the WARN from bdw_set_cdclk() that's trying to achieve
the same thing in a more limite fashion.

Also take the opportunity to refactor the code to use a common function
for dumping out a cdclk state.

Cc: Mika Kahola 
Cc: Manasi Navare 
Cc: Rodrigo Vivi 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_cdclk.c   | 30 +++---
 drivers/gpu/drm/i915/intel_display.c |  3 +++
 drivers/gpu/drm/i915/intel_drv.h |  2 ++
 3 files changed, 24 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
b/drivers/gpu/drm/i915/intel_cdclk.c
index fedfe3c720b6..51cd23dd8676 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -768,10 +768,6 @@ static void bdw_set_cdclk(struct drm_i915_private 
*dev_priv,
I915_WRITE(CDCLK_FREQ, DIV_ROUND_CLOSEST(cdclk, 1000) - 1);
 
intel_update_cdclk(dev_priv);
-
-   WARN(cdclk != dev_priv->cdclk.hw.cdclk,
-"cdclk requested %d kHz but got %d kHz\n",
-cdclk, dev_priv->cdclk.hw.cdclk);
 }
 
 static int skl_calc_cdclk(int min_cdclk, int vco)
@@ -1068,6 +1064,8 @@ static void skl_sanitize_cdclk(struct drm_i915_private 
*dev_priv)
goto sanitize;
 
intel_update_cdclk(dev_priv);
+   intel_dump_cdclk_state(&dev_priv->cdclk.hw, "Current CDCLK");
+
/* Is PLL enabled and locked ? */
if (dev_priv->cdclk.hw.vco == 0 ||
dev_priv->cdclk.hw.cdclk == dev_priv->cdclk.hw.ref)
@@ -1407,6 +1405,7 @@ static void bxt_sanitize_cdclk(struct drm_i915_private 
*dev_priv)
u32 cdctl, expected;
 
intel_update_cdclk(dev_priv);
+   intel_dump_cdclk_state(&dev_priv->cdclk.hw, "Current CDCLK");
 
if (dev_priv->cdclk.hw.vco == 0 ||
dev_priv->cdclk.hw.cdclk == dev_priv->cdclk.hw.ref)
@@ -1713,6 +1712,7 @@ static void cnl_sanitize_cdclk(struct drm_i915_private 
*dev_priv)
u32 cdctl, expected;
 
intel_update_cdclk(dev_priv);
+   intel_dump_cdclk_state(&dev_priv->cdclk.hw, "Current CDCLK");
 
if (dev_priv->cdclk.hw.vco == 0 ||
dev_priv->cdclk.hw.cdclk == dev_priv->cdclk.hw.ref)
@@ -1826,6 +1826,14 @@ bool intel_cdclk_changed(const struct intel_cdclk_state 
*a,
a->voltage_level != b->voltage_level;
 }
 
+void intel_dump_cdclk_state(const struct intel_cdclk_state *cdclk_state,
+   const char *context)
+{
+   DRM_DEBUG_DRIVER("%s %d kHz, VCO %d kHz, ref %d kHz, voltage level 
%d\n",
+context, cdclk_state->cdclk, cdclk_state->vco,
+cdclk_state->ref, cdclk_state->voltage_level);
+}
+
 /**
  * intel_set_cdclk - Push the CDCLK state to the hardware
  * @dev_priv: i915 device
@@ -1843,11 +1851,15 @@ void intel_set_cdclk(struct drm_i915_private *dev_priv,
if (WARN_ON_ONCE(!dev_priv->display.set_cdclk))
return;
 
-   DRM_DEBUG_DRIVER("Changing CDCLK to %d kHz, VCO %d kHz, ref %d kHz, 
voltage_level %d\n",
-cdclk_state->cdclk, cdclk_state->vco,
-cdclk_state->ref, cdclk_state->voltage_level);
+   intel_dump_cdclk_state(cdclk_state, "Changing CDCLK to");
 
dev_priv->display.set_cdclk(dev_priv, cdclk_state);
+
+   if (WARN(intel_cdclk_changed(&dev_priv->cdclk.hw, cdclk_state),
+"cdclk state doesn't match!\n")) {
+   intel_dump_cdclk_state(&dev_priv->cdclk.hw, "[hw state]");
+   intel_dump_cdclk_state(cdclk_state, "[sw state]");
+   }
 }
 
 static int intel_pixel_rate_to_cdclk(struct drm_i915_private *dev_priv,
@@ -2280,10 +2292,6 @@ void intel_update_cdclk(struct drm_i915_private 
*dev_priv)
 {
dev_priv->display.get_cdclk(dev_priv, &dev_priv->cdclk.hw);
 
-   DRM_DEBUG_DRIVER("Current CD clock rate: %d kHz, VCO: %d kHz, ref: %d 
kHz\n",
-dev_priv->cdclk.hw.cdclk, dev_priv->cdclk.hw.vco,
-dev_priv->cdclk.hw.ref);
-
/*
 * 9:0 CMBUS [sic] CDCLK frequency (cdfreq):
 * Programmng [sic] note: bit[9:2] should be programmed to the number
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index b5fa643e1812..7d7952b78a3b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8857,7 +8857,9 @@ static void hsw_restore_lcpll(struct drm_i915_private 
*dev_priv)
}
 
intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
+
intel_update_cdclk(dev_priv);
+   intel_dump_cdclk_state(&dev_priv->cdclk.hw, "Current CDCLK");
 }
 
 /*
@@ -14358,6 +14360,7 @@ void intel_modeset_init_hw(struct drm_device *dev)
struct drm_i915_private *dev_priv = to_i915(dev);
 
intel_update_cdclk(dev_priv);
+   intel_dump_cdclk_state(&dev_priv->cdclk.hw, "Current CDC

[Intel-gfx] [PATCH v2 05/10] drm/i915: Use cdclk_state->voltage on SKL/KBL/CFL

2017-10-24 Thread Ville Syrjala
From: Ville Syrjälä 

Track the system agent voltage we request from pcode in the cdclk state
on SKL/KBL/CFL. Annoyingly we can't actually read out the current value since
there's no pcode command to do that, so we'll have to just assume that
it worked.

v2: s/voltage/voltage_level/ (Rodrigo)

Cc: Mika Kahola 
Cc: Manasi Navare 
Cc: Rodrigo Vivi 
Signed-off-by: Ville Syrjälä 
Reviewed-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_cdclk.c | 43 +++---
 1 file changed, 36 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
b/drivers/gpu/drm/i915/intel_cdclk.c
index c98fec333dd1..38e31df265bd 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -785,6 +785,24 @@ static int skl_calc_cdclk(int min_cdclk, int vco)
}
 }
 
+static u8 skl_calc_voltage_level(int cdclk)
+{
+   switch (cdclk) {
+   default:
+   case 308571:
+   case 337500:
+   return 0;
+   case 45:
+   case 432000:
+   return 1;
+   case 54:
+   return 2;
+   case 617143:
+   case 675000:
+   return 3;
+   }
+}
+
 static void skl_dpll0_update(struct drm_i915_private *dev_priv,
 struct intel_cdclk_state *cdclk_state)
 {
@@ -835,7 +853,7 @@ static void skl_get_cdclk(struct drm_i915_private *dev_priv,
cdclk_state->cdclk = cdclk_state->ref;
 
if (cdclk_state->vco == 0)
-   return;
+   goto out;
 
cdctl = I915_READ(CDCLK_CTL);
 
@@ -876,6 +894,14 @@ static void skl_get_cdclk(struct drm_i915_private 
*dev_priv,
break;
}
}
+
+ out:
+   /*
+* Can't read this out :( Let's assume it's
+* at least what the CDCLK frequency requires.
+*/
+   cdclk_state->voltage_level =
+   skl_calc_voltage_level(cdclk_state->cdclk);
 }
 
 /* convert from kHz to .1 fixpoint MHz with -1MHz offset */
@@ -960,7 +986,7 @@ static void skl_set_cdclk(struct drm_i915_private *dev_priv,
 {
int cdclk = cdclk_state->cdclk;
int vco = cdclk_state->vco;
-   u32 freq_select, pcu_ack;
+   u32 freq_select;
int ret;
 
mutex_lock(&dev_priv->pcu_lock);
@@ -984,21 +1010,17 @@ static void skl_set_cdclk(struct drm_i915_private 
*dev_priv,
case 308571:
case 337500:
freq_select = CDCLK_FREQ_337_308;
-   pcu_ack = 0;
break;
case 45:
case 432000:
freq_select = CDCLK_FREQ_450_432;
-   pcu_ack = 1;
break;
case 54:
freq_select = CDCLK_FREQ_540;
-   pcu_ack = 2;
break;
case 617143:
case 675000:
freq_select = CDCLK_FREQ_675_617;
-   pcu_ack = 3;
break;
}
 
@@ -1014,7 +1036,8 @@ static void skl_set_cdclk(struct drm_i915_private 
*dev_priv,
 
/* inform PCU of the change */
mutex_lock(&dev_priv->pcu_lock);
-   sandybridge_pcode_write(dev_priv, SKL_PCODE_CDCLK_CONTROL, pcu_ack);
+   sandybridge_pcode_write(dev_priv, SKL_PCODE_CDCLK_CONTROL,
+   cdclk_state->voltage_level);
mutex_unlock(&dev_priv->pcu_lock);
 
intel_update_cdclk(dev_priv);
@@ -1093,6 +1116,7 @@ void skl_init_cdclk(struct drm_i915_private *dev_priv)
if (cdclk_state.vco == 0)
cdclk_state.vco = 810;
cdclk_state.cdclk = skl_calc_cdclk(0, cdclk_state.vco);
+   cdclk_state.voltage_level = skl_calc_voltage_level(cdclk_state.cdclk);
 
skl_set_cdclk(dev_priv, &cdclk_state);
 }
@@ -1110,6 +1134,7 @@ void skl_uninit_cdclk(struct drm_i915_private *dev_priv)
 
cdclk_state.cdclk = cdclk_state.ref;
cdclk_state.vco = 0;
+   cdclk_state.voltage_level = skl_calc_voltage_level(cdclk_state.cdclk);
 
skl_set_cdclk(dev_priv, &cdclk_state);
 }
@@ -1968,12 +1993,16 @@ static int skl_modeset_calc_cdclk(struct 
drm_atomic_state *state)
 
intel_state->cdclk.logical.vco = vco;
intel_state->cdclk.logical.cdclk = cdclk;
+   intel_state->cdclk.logical.voltage_level =
+   skl_calc_voltage_level(cdclk);
 
if (!intel_state->active_crtcs) {
cdclk = skl_calc_cdclk(0, vco);
 
intel_state->cdclk.actual.vco = vco;
intel_state->cdclk.actual.cdclk = cdclk;
+   intel_state->cdclk.actual.voltage_level =
+   skl_calc_voltage_level(cdclk);
} else {
intel_state->cdclk.actual =
intel_state->cdclk.logical;
-- 
2.13.6

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


Re: [Intel-gfx] [PATCH v2 00/10] drm/i915: CNL DVFS thing

2017-10-24 Thread Ville Syrjälä
On Tue, Oct 24, 2017 at 12:52:06PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> New version of the CNL DVFS series. Everything from the previous series
> (first 8 patches) are already reviewed. I slapped on two additional patches
> that fell out from the review of the first series.

Oh, and I forgot to mention that the other main change from the previous
series is that we now talk about "voltage_level" rather than "voltage"
everywhere. That required changes to almost all the patches, hence I
sent out a new full series.

> 
> Entire series available here:
> git://github.com/vsyrjala/linux.git dvfs_voltage_6
> 
> Ville Syrjälä (10):
>   drm/i915: Clean up some cdclk switch statements
>   drm/i915: Start tracking voltage level in the cdclk state
>   drm/i915: Use cdclk_state->voltage on VLV/CHV
>   drm/i915: Use cdclk_state->voltage on BDW
>   drm/i915: Use cdclk_state->voltage on SKL/KBL/CFL
>   drm/i915: Use cdclk_state->voltage on BXT/GLK
>   drm/i915: Use cdclk_state->voltage on CNL
>   drm/i915: Adjust system agent voltage on CNL if required by DDI ports
>   drm/i915: Sanity check cdclk in vlv_set_cdclk()
>   drm/i915: Perform a central cdclk state sanity check
> 
>  drivers/gpu/drm/i915/i915_drv.h |   3 +
>  drivers/gpu/drm/i915/intel_cdclk.c  | 377 
> 
>  drivers/gpu/drm/i915/intel_ddi.c|  11 +
>  drivers/gpu/drm/i915/intel_display.c|  22 +-
>  drivers/gpu/drm/i915/intel_dp_mst.c |   5 +
>  drivers/gpu/drm/i915/intel_dpll_mgr.c   |  16 +-
>  drivers/gpu/drm/i915/intel_drv.h|  13 +-
>  drivers/gpu/drm/i915/intel_runtime_pm.c |   3 +-
>  8 files changed, 342 insertions(+), 108 deletions(-)
> 
> -- 
> 2.13.6

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


Re: [Intel-gfx] [PATCH] drm/i915/cnl: Symmetric scalers for each pipe

2017-10-24 Thread Maiti, Nabendu Bikash



On 10/11/2017 6:38 PM, Mika Kahola wrote:

On Wed, 2017-10-11 at 15:43 +0300, Ville Syrjälä wrote:

On Mon, Oct 09, 2017 at 03:26:07PM +0300, Mika Kahola wrote:

For Cannonlake the number of scalers for each pipe is 2. Let's
increase
the number of scalers for pipe C.

Signed-off-by: Mika Kahola 
---
  drivers/gpu/drm/i915/intel_device_info.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_device_info.c
b/drivers/gpu/drm/i915/intel_device_info.c
index 875d428..b2ab6cb 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -347,7 +347,10 @@ void intel_device_info_runtime_init(struct
drm_i915_private *dev_priv)
    struct intel_device_info *info =
mkwrite_device_info(dev_priv);
    enum pipe pipe;
  
-	if (INTEL_GEN(dev_priv) >= 9) {

+   if (IS_CANNONLAKE(dev_priv)) {

GEN >= 10 would be a bit more future proof.

That's true. I actually tried this on trybot but the outcome wasn't
clean. Maybe I just switch back and give CI another go.

Similar patch I submitted in internal (merged).



+   for_each_pipe(dev_priv, pipe)
+   info->num_scalers[pipe] = 2;
+   } else if (INTEL_GEN(dev_priv) >= 9) {
    info->num_scalers[PIPE_A] = 2;
    info->num_scalers[PIPE_B] = 2;
    info->num_scalers[PIPE_C] = 1;
--
2.7.4

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

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


[Intel-gfx] [PATCH 1/1] drm/i915: Save PM interrupt register offsets in device info

2017-10-24 Thread Sagar Arun Kamble
PM interrupt register offsets are constant per platforms and saving those
in device info is more appropriate than getting those through functions.
This patch removes functions gen6_pm_iir/imr/ier and saves those offsets
in device info.

Suggested-by: Tvrtko Ursulin 
Signed-off-by: Sagar Arun Kamble 
Cc: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_drv.h  |  5 +
 drivers/gpu/drm/i915/i915_irq.c  | 30 --
 drivers/gpu/drm/i915/intel_device_info.c | 11 +++
 3 files changed, 24 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 54b5d4c..2f77d26 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -888,6 +888,11 @@ struct intel_device_info {
u16 degamma_lut_size;
u16 gamma_lut_size;
} color;
+
+   /* PM interrupt register offsets */
+   i915_reg_t pm_iir_offset;
+   i915_reg_t pm_imr_offset;
+   i915_reg_t pm_ier_offset;
 };
 
 struct intel_display_error_state;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index b1296a5..68c6f44 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -306,21 +306,6 @@ void gen5_disable_gt_irq(struct drm_i915_private 
*dev_priv, uint32_t mask)
ilk_update_gt_irq(dev_priv, mask, 0);
 }
 
-static i915_reg_t gen6_pm_iir(struct drm_i915_private *dev_priv)
-{
-   return INTEL_GEN(dev_priv) >= 8 ? GEN8_GT_IIR(2) : GEN6_PMIIR;
-}
-
-static i915_reg_t gen6_pm_imr(struct drm_i915_private *dev_priv)
-{
-   return INTEL_GEN(dev_priv) >= 8 ? GEN8_GT_IMR(2) : GEN6_PMIMR;
-}
-
-static i915_reg_t gen6_pm_ier(struct drm_i915_private *dev_priv)
-{
-   return INTEL_GEN(dev_priv) >= 8 ? GEN8_GT_IER(2) : GEN6_PMIER;
-}
-
 /**
  * snb_update_pm_irq - update GEN6_PMIMR
  * @dev_priv: driver private
@@ -343,8 +328,8 @@ static void snb_update_pm_irq(struct drm_i915_private 
*dev_priv,
 
if (new_val != dev_priv->pm_imr) {
dev_priv->pm_imr = new_val;
-   I915_WRITE(gen6_pm_imr(dev_priv), dev_priv->pm_imr);
-   POSTING_READ(gen6_pm_imr(dev_priv));
+   I915_WRITE(dev_priv->info.pm_imr_offset, dev_priv->pm_imr);
+   POSTING_READ(dev_priv->info.pm_imr_offset);
}
 }
 
@@ -371,7 +356,7 @@ void gen6_mask_pm_irq(struct drm_i915_private *dev_priv, 
u32 mask)
 
 static void gen6_reset_pm_iir(struct drm_i915_private *dev_priv, u32 
reset_mask)
 {
-   i915_reg_t reg = gen6_pm_iir(dev_priv);
+   i915_reg_t reg = dev_priv->info.pm_iir_offset;
 
lockdep_assert_held(&dev_priv->irq_lock);
 
@@ -385,7 +370,7 @@ static void gen6_enable_pm_irq(struct drm_i915_private 
*dev_priv, u32 enable_mas
lockdep_assert_held(&dev_priv->irq_lock);
 
dev_priv->pm_ier |= enable_mask;
-   I915_WRITE(gen6_pm_ier(dev_priv), dev_priv->pm_ier);
+   I915_WRITE(dev_priv->info.pm_ier_offset, dev_priv->pm_ier);
gen6_unmask_pm_irq(dev_priv, enable_mask);
/* unmask_pm_irq provides an implicit barrier (POSTING_READ) */
 }
@@ -396,7 +381,7 @@ static void gen6_disable_pm_irq(struct drm_i915_private 
*dev_priv, u32 disable_m
 
dev_priv->pm_ier &= ~disable_mask;
__gen6_mask_pm_irq(dev_priv, disable_mask);
-   I915_WRITE(gen6_pm_ier(dev_priv), dev_priv->pm_ier);
+   I915_WRITE(dev_priv->info.pm_ier_offset, dev_priv->pm_ier);
/* though a barrier is missing here, but don't really need a one */
 }
 
@@ -417,7 +402,8 @@ void gen6_enable_rps_interrupts(struct drm_i915_private 
*dev_priv)
 
spin_lock_irq(&dev_priv->irq_lock);
WARN_ON_ONCE(rps->pm_iir);
-   WARN_ON_ONCE(I915_READ(gen6_pm_iir(dev_priv)) & 
dev_priv->pm_rps_events);
+   WARN_ON_ONCE(I915_READ(dev_priv->info.pm_iir_offset) &
+  dev_priv->pm_rps_events);
rps->interrupts_enabled = true;
gen6_enable_pm_irq(dev_priv, dev_priv->pm_rps_events);
 
@@ -461,7 +447,7 @@ void gen9_enable_guc_interrupts(struct drm_i915_private 
*dev_priv)
 {
spin_lock_irq(&dev_priv->irq_lock);
if (!dev_priv->guc.interrupts_enabled) {
-   WARN_ON_ONCE(I915_READ(gen6_pm_iir(dev_priv)) &
+   WARN_ON_ONCE(I915_READ(dev_priv->info.pm_iir_offset) &
   dev_priv->pm_guc_events);
dev_priv->guc.interrupts_enabled = true;
gen6_enable_pm_irq(dev_priv, dev_priv->pm_guc_events);
diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i915/intel_device_info.c
index 875d428..d1a4911 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -462,4 +462,15 @@ void intel_device_info_runtime_init(struct 
drm_i915_private *dev_priv)
 info->sseu.has_subslice_pg ? "y" : "n");
DRM_DEBUG_DRIVER

Re: [Intel-gfx] [PATCH 1/1] drm/i915: Save PM interrupt register offsets in device info

2017-10-24 Thread Chris Wilson
Quoting Sagar Arun Kamble (2017-10-24 11:10:50)
> PM interrupt register offsets are constant per platforms and saving those
> in device info is more appropriate than getting those through functions.
> This patch removes functions gen6_pm_iir/imr/ier and saves those offsets
> in device info.
> 
> Suggested-by: Tvrtko Ursulin 
> Signed-off-by: Sagar Arun Kamble 
> Cc: Chris Wilson 
> Cc: Tvrtko Ursulin 
> Cc: Joonas Lahtinen 

What direction are we taking on INTEL_INFO() vs i915->info?

INTEL_INFO still offers the bait-n-switch promise of single-gen
compilation...
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v2 1/1] drm/i915: Save PM interrupt register offsets in device info

2017-10-24 Thread Sagar Arun Kamble
PM interrupt register offsets are constant per platforms and saving those
in device info is more appropriate than getting those through functions.
This patch removes functions gen6_pm_iir/imr/ier and saves those offsets
in device info.

v2: Use INTEL_INFO() to access device info. (Chris)

Suggested-by: Tvrtko Ursulin 
Signed-off-by: Sagar Arun Kamble 
Cc: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_drv.h  |  5 +
 drivers/gpu/drm/i915/i915_irq.c  | 31 +--
 drivers/gpu/drm/i915/intel_device_info.c | 11 +++
 3 files changed, 25 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 54b5d4c..2f77d26 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -888,6 +888,11 @@ struct intel_device_info {
u16 degamma_lut_size;
u16 gamma_lut_size;
} color;
+
+   /* PM interrupt register offsets */
+   i915_reg_t pm_iir_offset;
+   i915_reg_t pm_imr_offset;
+   i915_reg_t pm_ier_offset;
 };
 
 struct intel_display_error_state;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index b1296a5..5d448af 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -306,21 +306,6 @@ void gen5_disable_gt_irq(struct drm_i915_private 
*dev_priv, uint32_t mask)
ilk_update_gt_irq(dev_priv, mask, 0);
 }
 
-static i915_reg_t gen6_pm_iir(struct drm_i915_private *dev_priv)
-{
-   return INTEL_GEN(dev_priv) >= 8 ? GEN8_GT_IIR(2) : GEN6_PMIIR;
-}
-
-static i915_reg_t gen6_pm_imr(struct drm_i915_private *dev_priv)
-{
-   return INTEL_GEN(dev_priv) >= 8 ? GEN8_GT_IMR(2) : GEN6_PMIMR;
-}
-
-static i915_reg_t gen6_pm_ier(struct drm_i915_private *dev_priv)
-{
-   return INTEL_GEN(dev_priv) >= 8 ? GEN8_GT_IER(2) : GEN6_PMIER;
-}
-
 /**
  * snb_update_pm_irq - update GEN6_PMIMR
  * @dev_priv: driver private
@@ -332,6 +317,7 @@ static void snb_update_pm_irq(struct drm_i915_private 
*dev_priv,
  uint32_t enabled_irq_mask)
 {
uint32_t new_val;
+   i915_reg_t reg = INTEL_INFO(dev_priv)->pm_imr_offset;
 
WARN_ON(enabled_irq_mask & ~interrupt_mask);
 
@@ -343,8 +329,8 @@ static void snb_update_pm_irq(struct drm_i915_private 
*dev_priv,
 
if (new_val != dev_priv->pm_imr) {
dev_priv->pm_imr = new_val;
-   I915_WRITE(gen6_pm_imr(dev_priv), dev_priv->pm_imr);
-   POSTING_READ(gen6_pm_imr(dev_priv));
+   I915_WRITE(reg, dev_priv->pm_imr);
+   POSTING_READ(reg);
}
 }
 
@@ -371,7 +357,7 @@ void gen6_mask_pm_irq(struct drm_i915_private *dev_priv, 
u32 mask)
 
 static void gen6_reset_pm_iir(struct drm_i915_private *dev_priv, u32 
reset_mask)
 {
-   i915_reg_t reg = gen6_pm_iir(dev_priv);
+   i915_reg_t reg = INTEL_INFO(dev_priv)->pm_iir_offset;
 
lockdep_assert_held(&dev_priv->irq_lock);
 
@@ -385,7 +371,7 @@ static void gen6_enable_pm_irq(struct drm_i915_private 
*dev_priv, u32 enable_mas
lockdep_assert_held(&dev_priv->irq_lock);
 
dev_priv->pm_ier |= enable_mask;
-   I915_WRITE(gen6_pm_ier(dev_priv), dev_priv->pm_ier);
+   I915_WRITE(INTEL_INFO(dev_priv)->pm_ier_offset, dev_priv->pm_ier);
gen6_unmask_pm_irq(dev_priv, enable_mask);
/* unmask_pm_irq provides an implicit barrier (POSTING_READ) */
 }
@@ -396,7 +382,7 @@ static void gen6_disable_pm_irq(struct drm_i915_private 
*dev_priv, u32 disable_m
 
dev_priv->pm_ier &= ~disable_mask;
__gen6_mask_pm_irq(dev_priv, disable_mask);
-   I915_WRITE(gen6_pm_ier(dev_priv), dev_priv->pm_ier);
+   I915_WRITE(INTEL_INFO(dev_priv)->pm_ier_offset, dev_priv->pm_ier);
/* though a barrier is missing here, but don't really need a one */
 }
 
@@ -417,7 +403,8 @@ void gen6_enable_rps_interrupts(struct drm_i915_private 
*dev_priv)
 
spin_lock_irq(&dev_priv->irq_lock);
WARN_ON_ONCE(rps->pm_iir);
-   WARN_ON_ONCE(I915_READ(gen6_pm_iir(dev_priv)) & 
dev_priv->pm_rps_events);
+   WARN_ON_ONCE(I915_READ(INTEL_INFO(dev_priv)->pm_iir_offset) &
+  dev_priv->pm_rps_events);
rps->interrupts_enabled = true;
gen6_enable_pm_irq(dev_priv, dev_priv->pm_rps_events);
 
@@ -461,7 +448,7 @@ void gen9_enable_guc_interrupts(struct drm_i915_private 
*dev_priv)
 {
spin_lock_irq(&dev_priv->irq_lock);
if (!dev_priv->guc.interrupts_enabled) {
-   WARN_ON_ONCE(I915_READ(gen6_pm_iir(dev_priv)) &
+   WARN_ON_ONCE(I915_READ(INTEL_INFO(dev_priv)->pm_iir_offset) &
   dev_priv->pm_guc_events);
dev_priv->guc.interrupts_enabled = true;
gen6_enable_pm_irq(dev_priv, dev_priv->pm_guc_events);
diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
b/drivers/gpu/drm/i9

[Intel-gfx] [PATCH i-g-t] run-tests.sh: Use piglit names when listing available tests

2017-10-24 Thread Petri Latvala
List the available tests with piglit instead of by hand. This solves
naming inconsistencies (piglit throwing caps away) as seen by
cibuglog, and makes the listing code simpler.

The format of the listing changes from

 test-binary/subtest-name

to

 igt@test-binary@subtest-name

but so far nothing has been able to directly consume run-tests.sh -l
output. The piglit format is directly consumable by piglit --test-list, and thus
by run-tests.sh -T.

Signed-off-by: Petri Latvala 
Cc: Tomi Sarvela 
Cc: Arkadiusz Hiler 
---

This patch cannot be merged without explicit confirmation from Tomi
and Arek that the CI side is ready for this. Today, this will break
sharded runs.


scripts/run-tests.sh | 22 ++
 1 file changed, 6 insertions(+), 16 deletions(-)

diff --git a/scripts/run-tests.sh b/scripts/run-tests.sh
index a28dd876..acd2ae2f 100755
--- a/scripts/run-tests.sh
+++ b/scripts/run-tests.sh
@@ -40,8 +40,6 @@ if [ ! -f "$IGT_TEST_ROOT/test-list.txt" ]; then
exit 1
 fi
 
-TEST_LIST=`cat "$IGT_TEST_ROOT/test-list.txt" | sed -e '/TESTLIST/d' -e 's/ 
/\n/g'`
-
 function download_piglit {
git clone git://anongit.freedesktop.org/piglit "$ROOT/piglit"
 }
@@ -70,24 +68,11 @@ function print_help {
echo "Useful patterns for test filtering are described in the API 
documentation."
 }
 
-function list_tests {
-   for test in $TEST_LIST; do
-   SUBTESTS=`"$IGT_TEST_ROOT/$test" --list-subtests`
-   if [ -z "$SUBTESTS" ]; then
-   echo "$test"
-   else
-   for subtest in $SUBTESTS; do
-   echo "$test/$subtest"
-   done
-   fi
-   done
-}
-
 while getopts ":dhlr:st:T:vx:Rn" opt; do
case $opt in
d) download_piglit; exit ;;
h) print_help; exit ;;
-   l) list_tests; exit ;;
+   l) LIST_TESTS="true" ;;
r) RESULTS="$OPTARG" ;;
s) SUMMARY="html" ;;
t) FILTER="$FILTER -t $OPTARG" ;;
@@ -125,6 +110,11 @@ if [ ! -x "$PIGLIT" ]; then
exit 1
 fi
 
+if [ "x$LIST_TESTS" != "x" ]; then
+   IGT_TEST_ROOT="$IGT_TEST_ROOT" IGT_CONFIG_PATH="$IGT_CONFIG_PATH" 
"$PIGLIT" print-cmd --format "{name}" igt
+   exit
+fi
+
 if [ "x$RESUME" != "x" ]; then
sudo IGT_TEST_ROOT="$IGT_TEST_ROOT" IGT_CONFIG_PATH="$IGT_CONFIG_PATH" 
"$PIGLIT" resume "$RESULTS" $NORETRY
 else
-- 
2.14.1

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


Re: [Intel-gfx] [PATCH v2 1/1] drm/i915: Save PM interrupt register offsets in device info

2017-10-24 Thread Michal Wajdeczko
On Tue, 24 Oct 2017 12:41:13 +0200, Sagar Arun Kamble  
 wrote:



PM interrupt register offsets are constant per platforms and saving those
in device info is more appropriate than getting those through functions.
This patch removes functions gen6_pm_iir/imr/ier and saves those offsets
in device info.

v2: Use INTEL_INFO() to access device info. (Chris)

Suggested-by: Tvrtko Ursulin 
Signed-off-by: Sagar Arun Kamble 
Cc: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_drv.h  |  5 +
 drivers/gpu/drm/i915/i915_irq.c  | 31  
+--

 drivers/gpu/drm/i915/intel_device_info.c | 11 +++
 3 files changed, 25 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h  
b/drivers/gpu/drm/i915/i915_drv.h

index 54b5d4c..2f77d26 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -888,6 +888,11 @@ struct intel_device_info {
u16 degamma_lut_size;
u16 gamma_lut_size;
} color;
+
+   /* PM interrupt register offsets */
+   i915_reg_t pm_iir_offset;
+   i915_reg_t pm_imr_offset;
+   i915_reg_t pm_ier_offset;
 };
struct intel_display_error_state;
diff --git a/drivers/gpu/drm/i915/i915_irq.c  
b/drivers/gpu/drm/i915/i915_irq.c

index b1296a5..5d448af 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -306,21 +306,6 @@ void gen5_disable_gt_irq(struct drm_i915_private  
*dev_priv, uint32_t mask)

ilk_update_gt_irq(dev_priv, mask, 0);
 }
-static i915_reg_t gen6_pm_iir(struct drm_i915_private *dev_priv)
-{
-   return INTEL_GEN(dev_priv) >= 8 ? GEN8_GT_IIR(2) : GEN6_PMIIR;
-}
-
-static i915_reg_t gen6_pm_imr(struct drm_i915_private *dev_priv)
-{
-   return INTEL_GEN(dev_priv) >= 8 ? GEN8_GT_IMR(2) : GEN6_PMIMR;
-}
-
-static i915_reg_t gen6_pm_ier(struct drm_i915_private *dev_priv)
-{
-   return INTEL_GEN(dev_priv) >= 8 ? GEN8_GT_IER(2) : GEN6_PMIER;
-}
-


btw, if you keep these functions but modify them into:

return INTEL_INFO(dev_priv)->pm_xxx_offset;

then most of below changes will not be needed


 /**
  * snb_update_pm_irq - update GEN6_PMIMR
  * @dev_priv: driver private
@@ -332,6 +317,7 @@ static void snb_update_pm_irq(struct  
drm_i915_private *dev_priv,

  uint32_t enabled_irq_mask)
 {
uint32_t new_val;
+   i915_reg_t reg = INTEL_INFO(dev_priv)->pm_imr_offset;


s/reg/imr ?


WARN_ON(enabled_irq_mask & ~interrupt_mask);
@@ -343,8 +329,8 @@ static void snb_update_pm_irq(struct  
drm_i915_private *dev_priv,

if (new_val != dev_priv->pm_imr) {
dev_priv->pm_imr = new_val;
-   I915_WRITE(gen6_pm_imr(dev_priv), dev_priv->pm_imr);
-   POSTING_READ(gen6_pm_imr(dev_priv));
+   I915_WRITE(reg, dev_priv->pm_imr);
+   POSTING_READ(reg);
}
 }
@@ -371,7 +357,7 @@ void gen6_mask_pm_irq(struct drm_i915_private  
*dev_priv, u32 mask)
static void gen6_reset_pm_iir(struct drm_i915_private *dev_priv, u32  
reset_mask)

 {
-   i915_reg_t reg = gen6_pm_iir(dev_priv);
+   i915_reg_t reg = INTEL_INFO(dev_priv)->pm_iir_offset;


s/reg/iir ?


lockdep_assert_held(&dev_priv->irq_lock);
@@ -385,7 +371,7 @@ static void gen6_enable_pm_irq(struct  
drm_i915_private *dev_priv, u32 enable_mas

lockdep_assert_held(&dev_priv->irq_lock);
dev_priv->pm_ier |= enable_mask;
-   I915_WRITE(gen6_pm_ier(dev_priv), dev_priv->pm_ier);
+   I915_WRITE(INTEL_INFO(dev_priv)->pm_ier_offset, dev_priv->pm_ier);
gen6_unmask_pm_irq(dev_priv, enable_mask);
/* unmask_pm_irq provides an implicit barrier (POSTING_READ) */
 }
@@ -396,7 +382,7 @@ static void gen6_disable_pm_irq(struct  
drm_i915_private *dev_priv, u32 disable_m

dev_priv->pm_ier &= ~disable_mask;
__gen6_mask_pm_irq(dev_priv, disable_mask);
-   I915_WRITE(gen6_pm_ier(dev_priv), dev_priv->pm_ier);
+   I915_WRITE(INTEL_INFO(dev_priv)->pm_ier_offset, dev_priv->pm_ier);
/* though a barrier is missing here, but don't really need a one */
 }
@@ -417,7 +403,8 @@ void gen6_enable_rps_interrupts(struct  
drm_i915_private *dev_priv)

spin_lock_irq(&dev_priv->irq_lock);
WARN_ON_ONCE(rps->pm_iir);
-	WARN_ON_ONCE(I915_READ(gen6_pm_iir(dev_priv)) &  
dev_priv->pm_rps_events);

+   WARN_ON_ONCE(I915_READ(INTEL_INFO(dev_priv)->pm_iir_offset) &
+  dev_priv->pm_rps_events);


Can you define separate iir_reg variable as in above functions to simplify
this nested statement ?


rps->interrupts_enabled = true;
gen6_enable_pm_irq(dev_priv, dev_priv->pm_rps_events);
@@ -461,7 +448,7 @@ void gen9_enable_guc_interrupts(struct  
drm_i915_private *dev_priv)

 {
spin_lock_irq(&dev_priv->irq_lock);
if (!dev_priv->guc.interrupts_enabled) {
-   WARN_ON_ONCE(I915_READ(gen6_pm_iir(dev_pr

[Intel-gfx] [PATCH] drm/i915/huc: Use helper function while waiting for DMA completion

2017-10-24 Thread Michal Wajdeczko
Waiting for DMA status register can be done with dedicated function.
Lets use it as additional bonus will be smaller driver footprint.

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_huc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_huc.c b/drivers/gpu/drm/i915/intel_huc.c
index c8a48cb..98d1725 100644
--- a/drivers/gpu/drm/i915/intel_huc.c
+++ b/drivers/gpu/drm/i915/intel_huc.c
@@ -151,7 +151,7 @@ static int huc_ucode_xfer(struct intel_uc_fw *huc_fw, 
struct i915_vma *vma)
I915_WRITE(DMA_CTRL, _MASKED_BIT_ENABLE(HUC_UKERNEL | START_DMA));
 
/* Wait for DMA to finish */
-   ret = wait_for((I915_READ(DMA_CTRL) & START_DMA) == 0, 100);
+   ret = intel_wait_for_register_fw(dev_priv, DMA_CTRL, START_DMA, 0, 100);
 
DRM_DEBUG_DRIVER("HuC DMA transfer wait over with ret %d\n", ret);
 
-- 
2.7.4

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


[Intel-gfx] [PATCH i-g-t] igt/lib: Ignoring subtest name case

2017-10-24 Thread Lukasz Fiedorowicz
Lists in intel-ci directory are kept in all lower case but the subtest
names are mix of lower and upper case.
Piglit is able to handle this but not every CI is using piglit. Changing
condition to ignore subtest names case.

Signed-off-by: Lukasz Fiedorowicz 
---
 lib/igt_core.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/lib/igt_core.c b/lib/igt_core.c
index 538a447..743e82b 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -965,10 +965,11 @@ bool __igt_run_subtest(const char *subtest_name)
}
 
if (run_single_subtest) {
-   if (uwildmat(subtest_name, run_single_subtest) == 0)
+   if (uwildmat(subtest_name, run_single_subtest)
+|| strcasecmp(subtest_name, run_single_subtest) == 0)
+run_single_subtest_found = true;
+   else
return false;
-   else
-   run_single_subtest_found = true;
}
 
if (skip_subtests_henceforth) {
-- 
2.9.5

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


[Intel-gfx] [PATCH igt] igt/gem_ctx_isolation: Check isolation of registers between contexts

2017-10-24 Thread Chris Wilson
A new context assumes that all of its registers are in the default state
when it is created. What may happen is that a register written by one
context may leak into the second, causing mass confusion.

Signed-off-by: Chris Wilson 
---
 tests/Makefile.sources|   1 +
 tests/gem_ctx_isolation.c | 351 ++
 2 files changed, 352 insertions(+)
 create mode 100644 tests/gem_ctx_isolation.c

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index ac9f90bc..d18b7461 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -57,6 +57,7 @@ TESTS_progs = \
gem_ctx_basic \
gem_ctx_create \
gem_ctx_exec \
+   gem_ctx_isolation \
gem_ctx_param \
gem_ctx_switch \
gem_ctx_thrash \
diff --git a/tests/gem_ctx_isolation.c b/tests/gem_ctx_isolation.c
new file mode 100644
index ..1569f5a8
--- /dev/null
+++ b/tests/gem_ctx_isolation.c
@@ -0,0 +1,351 @@
+/*
+ * 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 "igt.h"
+#include "igt_dummyload.h"
+
+#define MAX_REG 0x4
+#define NUM_REGS (MAX_REG / sizeof(uint32_t))
+
+#define PAGE_ALIGN(x) ALIGN(x, 4096)
+
+#define DIRTY 0x1
+#define UNSAFE 0x2
+
+enum {
+   RCS_MASK = 0x1,
+   BCS_MASK = 0x2,
+   VCS_MASK = 0x4,
+   VECS_MASK = 0x8,
+};
+
+#define ALL ~0u
+#define GEN_RANGE(x, y) ((ALL >> (32 - (y - x + 1))) << x)
+
+static const struct named_register {
+   const char *name;
+   unsigned int gen_mask;
+   unsigned int engine_mask;
+   uint32_t offset;
+} safe_registers[] = {
+   /* Keep in ascending offset order */
+   { "CTX_PREEMPT", GEN_RANGE(9, 10), RCS_MASK, 0x2248 },
+   { "CS_CHICKEN1", GEN_RANGE(9, 10), RCS_MASK, 0x2580 },
+   { "HDC_CHICKEN1", GEN_RANGE(9, 10), RCS_MASK, 0x7304 },
+   { "L3SQREG1", GEN_RANGE(8, 10), RCS_MASK, 0xb010 },
+   {}
+}, ignore_registers[] = {
+   { "RCS timestamp", ALL, RCS_MASK, 0x2358 },
+   { "VCS0 timestamp", ALL, VCS_MASK, 0x12358 },
+   { "VCS1 timestamp", ALL, VCS_MASK, 0x1c358 },
+   { "BCS timestamp", ALL, BCS_MASK, 0x22358 },
+   { "VECS timestamp", ALL, VECS_MASK, 0x1a358 },
+   {}
+};
+
+static const char *register_name(uint32_t offset)
+{
+   /* XXX bsearch? */
+   for (const struct named_register *r = safe_registers; r->name; r++) {
+   if (r->offset == offset)
+   return r->name;
+   }
+
+   return "unknown";
+}
+
+static bool ignore_register(uint32_t offset)
+{
+   for (const struct named_register *r = ignore_registers; r->name; r++) {
+   if (r->offset == offset)
+   return true;
+   }
+
+   return false;
+}
+
+static uint32_t read_all_regs(int fd,
+ uint32_t ctx, unsigned int engine,
+ unsigned int flags)
+{
+   struct drm_i915_gem_exec_object2 obj[2];
+   struct drm_i915_gem_relocation_entry *reloc;
+   struct drm_i915_gem_execbuffer2 execbuf;
+   unsigned int regs_size, batch_size;
+   unsigned int engine_bit, gen_bit;
+   uint32_t *batch, *b;
+
+   switch (engine & 0x63) {
+   case I915_EXEC_DEFAULT:
+   case I915_EXEC_RENDER:
+   engine_bit = RCS_MASK;
+   break;
+   case I915_EXEC_BLT:
+   engine_bit = BCS_MASK;
+   break;
+   case I915_EXEC_BSD:
+   engine_bit = VCS_MASK;
+   break;
+   case I915_EXEC_VEBOX:
+   engine_bit = VECS_MASK;
+   break;
+   default:
+   igt_assert(0);
+   }
+   gen_bit = 1 << intel_gen(intel_get_drm_devid(fd));
+
+   reloc = calloc(NUM_REGS, sizeof(*reloc));
+   igt_assert(reloc);
+
+   regs_size = NUM_REGS * sizeof(uint32_t);
+   regs_size = PAGE_ALIGN

Re: [Intel-gfx] [PATCH i-g-t] igt/lib: Ignoring subtest name case

2017-10-24 Thread Petri Latvala
On Tue, Oct 24, 2017 at 12:53:06PM +0200, Lukasz Fiedorowicz wrote:
> Lists in intel-ci directory are kept in all lower case but the subtest
> names are mix of lower and upper case.
> Piglit is able to handle this but not every CI is using piglit. Changing
> condition to ignore subtest names case.


This fails to match --run-subtest "*pipe-b" to foo-bar-pipe-B


-- 
Petri Latvala



> 
> Signed-off-by: Lukasz Fiedorowicz 
> ---
>  lib/igt_core.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/lib/igt_core.c b/lib/igt_core.c
> index 538a447..743e82b 100644
> --- a/lib/igt_core.c
> +++ b/lib/igt_core.c
> @@ -965,10 +965,11 @@ bool __igt_run_subtest(const char *subtest_name)
>   }
>  
>   if (run_single_subtest) {
> - if (uwildmat(subtest_name, run_single_subtest) == 0)
> + if (uwildmat(subtest_name, run_single_subtest)
> +|| strcasecmp(subtest_name, run_single_subtest) == 0)
> +run_single_subtest_found = true;
> + else
>   return false;
> - else
> - run_single_subtest_found = true;
>   }
>  
>   if (skip_subtests_henceforth) {
> -- 
> 2.9.5
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: CNL DVFS thing (rev7)

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

Series: drm/i915: CNL DVFS thing (rev7)
URL   : https://patchwork.freedesktop.org/series/32247/
State : failure

== Summary ==

Series 32247v7 drm/i915: CNL DVFS thing
https://patchwork.freedesktop.org/api/1.0/series/32247/revisions/7/mbox/

Test chamelium:
Subgroup dp-crc-fast:
pass   -> FAIL   (fi-kbl-7500u) fdo#102514
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-skl-6700hq)

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:442s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:453s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:370s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:522s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:264s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:498s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:500s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:493s
fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
time:476s
fi-cfl-s total:289  pass:253  dwarn:4   dfail:0   fail:0   skip:32  
time:556s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:420s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:249s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:578s
fi-glk-dsi   total:289  pass:258  dwarn:0   dfail:0   fail:1   skip:30  
time:487s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:425s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:427s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:427s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:487s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:458s
fi-kbl-7500u total:289  pass:263  dwarn:1   dfail:0   fail:1   skip:24  
time:482s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:576s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:474s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:584s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:544s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:455s
fi-skl-6700hqtotal:246  pass:221  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:520s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:501s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:456s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:563s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:414s

5c82a37eff83ab4e60e760fbaf03db5ba0563497 drm-tip: 2017y-10m-23d-18h-06m-28s UTC 
integration manifest
ec580f178e62 drm/i915: Perform a central cdclk state sanity check
394fd358e1f3 drm/i915: Sanity check cdclk in vlv_set_cdclk()
c335ee11442a drm/i915: Adjust system agent voltage on CNL if required by DDI 
ports
8c83dfa21c6d drm/i915: Use cdclk_state->voltage on CNL
65271db422a1 drm/i915: Use cdclk_state->voltage on BXT/GLK
eb7c4d1139ab drm/i915: Use cdclk_state->voltage on SKL/KBL/CFL
deb10eabc15e drm/i915: Use cdclk_state->voltage on BDW
e6ff0c197dd6 drm/i915: Use cdclk_state->voltage on VLV/CHV
cbb3881aac06 drm/i915: Start tracking voltage level in the cdclk state
fbbb9cbf05b7 drm/i915: Clean up some cdclk switch statements

== Logs ==

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


Re: [Intel-gfx] [PATCH igt] igt/gem_ctx_isolation: Check isolation of registers between contexts

2017-10-24 Thread Chris Wilson
Quoting Chris Wilson (2017-10-24 12:07:58)
> A new context assumes that all of its registers are in the default state
> when it is created. What may happen is that a register written by one
> context may leak into the second, causing mass confusion.
> 
> Signed-off-by: Chris Wilson 
> ---
>  tests/Makefile.sources|   1 +
>  tests/gem_ctx_isolation.c | 351 
> ++
>  2 files changed, 352 insertions(+)
>  create mode 100644 tests/gem_ctx_isolation.c
> 
> diff --git a/tests/Makefile.sources b/tests/Makefile.sources
> index ac9f90bc..d18b7461 100644
> --- a/tests/Makefile.sources
> +++ b/tests/Makefile.sources
> @@ -57,6 +57,7 @@ TESTS_progs = \
> gem_ctx_basic \
> gem_ctx_create \
> gem_ctx_exec \
> +   gem_ctx_isolation \
> gem_ctx_param \
> gem_ctx_switch \
> gem_ctx_thrash \
> diff --git a/tests/gem_ctx_isolation.c b/tests/gem_ctx_isolation.c
> new file mode 100644
> index ..1569f5a8
> --- /dev/null
> +++ b/tests/gem_ctx_isolation.c
> @@ -0,0 +1,351 @@
> +/*
> + * 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 "igt.h"
> +#include "igt_dummyload.h"
> +
> +#define MAX_REG 0x4
> +#define NUM_REGS (MAX_REG / sizeof(uint32_t))
> +
> +#define PAGE_ALIGN(x) ALIGN(x, 4096)
> +
> +#define DIRTY 0x1
> +#define UNSAFE 0x2
> +
> +enum {
> +   RCS_MASK = 0x1,
> +   BCS_MASK = 0x2,
> +   VCS_MASK = 0x4,
> +   VECS_MASK = 0x8,
> +};

We be nice to include these in the future intel_engine interface!

> +#define ALL ~0u
> +#define GEN_RANGE(x, y) ((ALL >> (32 - (y - x + 1))) << x)
> +
> +static const struct named_register {
> +   const char *name;
> +   unsigned int gen_mask;
> +   unsigned int engine_mask;
> +   uint32_t offset;
> +} safe_registers[] = {

This list is incomplete, we need the list of nonpriv registers.

> +   /* Keep in ascending offset order */
> +   { "CTX_PREEMPT", GEN_RANGE(9, 10), RCS_MASK, 0x2248 },
> +   { "CS_CHICKEN1", GEN_RANGE(9, 10), RCS_MASK, 0x2580 },
> +   { "HDC_CHICKEN1", GEN_RANGE(9, 10), RCS_MASK, 0x7304 },
> +   { "L3SQREG1", GEN_RANGE(8, 10), RCS_MASK, 0xb010 },
> +   {}
> +}, ignore_registers[] = {
> +   { "RCS timestamp", ALL, RCS_MASK, 0x2358 },
> +   { "VCS0 timestamp", ALL, VCS_MASK, 0x12358 },
> +   { "VCS1 timestamp", ALL, VCS_MASK, 0x1c358 },
> +   { "BCS timestamp", ALL, BCS_MASK, 0x22358 },
> +   { "VECS timestamp", ALL, VECS_MASK, 0x1a358 },
> +   {}
> +};

> +igt_main
> +{
> +   const unsigned int platform_validation = 0;

So UNSAFE is decidedly unsafe; is there anyway we can run tests only
during PV?

> +   int fd = -1;
> +
> +   igt_fixture {
> +   fd = drm_open_driver(DRIVER_INTEL);
> +   igt_require_gem(fd);
> +
> +   igt_require(gem_has_execlists(fd));

And we need an igt_ci_fail_on(gen >= KNOWN_GEN);

> +   /* check that we can create contexts. */
> +   gem_context_destroy(fd, gem_context_create(fd));
> +   }
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915/huc: Use helper function while waiting for DMA completion

2017-10-24 Thread Chris Wilson
Quoting Michal Wajdeczko (2017-10-24 11:50:56)
> Waiting for DMA status register can be done with dedicated function.
> Lets use it as additional bonus will be smaller driver footprint.
> 
> Signed-off-by: Michal Wajdeczko 
> Cc: Chris Wilson 
> Cc: Joonas Lahtinen 
> ---
>  drivers/gpu/drm/i915/intel_huc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_huc.c 
> b/drivers/gpu/drm/i915/intel_huc.c
> index c8a48cb..98d1725 100644
> --- a/drivers/gpu/drm/i915/intel_huc.c
> +++ b/drivers/gpu/drm/i915/intel_huc.c
> @@ -151,7 +151,7 @@ static int huc_ucode_xfer(struct intel_uc_fw *huc_fw, 
> struct i915_vma *vma)
> I915_WRITE(DMA_CTRL, _MASKED_BIT_ENABLE(HUC_UKERNEL | START_DMA));
>  
> /* Wait for DMA to finish */
> -   ret = wait_for((I915_READ(DMA_CTRL) & START_DMA) == 0, 100);
> +   ret = intel_wait_for_register_fw(dev_priv, DMA_CTRL, START_DMA, 0, 
> 100);
>  
> DRM_DEBUG_DRIVER("HuC DMA transfer wait over with ret %d\n", ret);

Reviewed-by: Chris Wilson 

Aside, what's the serialisation so that we only try to load one fw at a
time?
-Chris
___
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 [1/1] drm/i915: Save PM interrupt register offsets in device info

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

Series: series starting with [1/1] drm/i915: Save PM interrupt register offsets 
in device info
URL   : https://patchwork.freedesktop.org/series/32524/
State : failure

== Summary ==

Series 32524v1 series starting with [1/1] drm/i915: Save PM interrupt register 
offsets in device info
https://patchwork.freedesktop.org/api/1.0/series/32524/revisions/1/mbox/

Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-c:
pass   -> INCOMPLETE (fi-skl-6700hq)
Test drv_module_reload:
Subgroup basic-reload-inject:
pass   -> INCOMPLETE (fi-bwr-2160)

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:448s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:455s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:371s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:516s
fi-bwr-2160  total:288  pass:182  dwarn:0   dfail:0   fail:0   skip:105
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:495s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:495s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:489s
fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
time:477s
fi-cfl-s total:289  pass:253  dwarn:4   dfail:0   fail:0   skip:32  
time:551s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:420s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:249s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:575s
fi-glk-dsi   total:289  pass:258  dwarn:0   dfail:0   fail:1   skip:30  
time:488s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:427s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:427s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:435s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:497s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:460s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:494s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:572s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:478s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:580s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:552s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:443s
fi-skl-6700hqtotal:232  pass:207  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:516s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:501s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:459s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:556s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:415s

5c82a37eff83ab4e60e760fbaf03db5ba0563497 drm-tip: 2017y-10m-23d-18h-06m-28s UTC 
integration manifest
41730da16e6e drm/i915: Save PM interrupt register offsets in device info

== Logs ==

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


[Intel-gfx] [PATCH] drm/i915: Dump watermark info in i915_display_info.

2017-10-24 Thread Maarten Lankhorst
This will make it easier to debug whether the hardware watermarks match
what's calculated for intermediate and optimal watermarks.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 153 
 1 file changed, 153 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index c65e381b85f3..ac9ea47ac89f 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3170,6 +3170,158 @@ static void intel_scaler_info(struct seq_file *m, 
struct intel_crtc *intel_crtc)
}
 }
 
+static void intel_watermark_info(struct seq_file *m,
+struct drm_i915_private *dev_priv,
+struct intel_crtc *crtc)
+{
+   struct intel_crtc_state *crtc_state =
+   to_intel_crtc_state(crtc->base.state);
+   int i, j;
+   const char *names[3] = {
+   "hardware",
+   "intermediate",
+   "optimal"
+   };
+
+   if (INTEL_GEN(dev_priv) >= 9) {
+   struct skl_pipe_wm *wm = &crtc_state->wm.skl.optimal;
+   struct skl_ddb_entry *entry = &crtc_state->wm.skl.ddb;
+   struct skl_ddb_allocation *ddb = &dev_priv->wm.skl_hw.ddb;
+
+   seq_printf(m, "\tDDB allocation: start %u end %u, size %u\n",
+  entry->start, entry->end, skl_ddb_entry_size(entry));
+   for (i = 0; i < ARRAY_SIZE(ddb->plane[crtc->pipe]); i++) {
+   entry = &ddb->plane[crtc->pipe][i];
+
+   if (!skl_ddb_entry_size(entry))
+   continue;
+
+   seq_printf(m, "\t\tplane %d%c DDB allocation: start %u 
end %u, size %u, ",
+  i, pipe_name(crtc->pipe), entry->start, 
entry->end,
+  skl_ddb_entry_size(entry));
+
+   entry = &ddb->y_plane[crtc->pipe][i];
+   if (!skl_ddb_entry_size(entry))
+   continue;
+
+   seq_printf(m, "\t\tplane %d%c DDB Y allocation: start 
%u end %u, size %u, ",
+  i, pipe_name(crtc->pipe), entry->start, 
entry->end,
+  skl_ddb_entry_size(entry));
+   }
+
+   seq_printf(m, "\tLinetime: %u\n", wm->linetime);
+
+   for (i = 0; i < ARRAY_SIZE(wm->planes); i++) {
+   struct skl_plane_wm *pwm = &wm->planes[i];
+
+   seq_printf(m, "\tplane %d%c, wm enabled: %s",
+  i, pipe_name(crtc->pipe),
+  enableddisabled(pwm->wm[0].plane_en));
+   if (!pwm->wm[0].plane_en)
+   continue;
+
+   seq_printf(m, "\t\tTransition wm: %s, lines %u, blocks 
%u",
+  enableddisabled(pwm->trans_wm.plane_en),
+  pwm->trans_wm.plane_res_b, 
pwm->trans_wm.plane_res_l);
+
+   for (j = 0; j < ARRAY_SIZE(pwm->wm); j++) {
+   if (!pwm->wm[j].plane_en)
+   break;
+
+ seq_printf(m, "\t\tLevel[%u]: lines %u, 
blocks %u",
+j, pwm->trans_wm.plane_res_b,
+pwm->trans_wm.plane_res_l);
+   }
+   }
+   } else if (HAS_PCH_SPLIT(dev_priv)) {
+   struct intel_pipe_wm *wm;
+   struct intel_pipe_wm *wms[3] = {
+   &crtc->wm.active.ilk,
+   &crtc_state->wm.ilk.intermediate,
+   &crtc_state->wm.ilk.optimal };
+
+   for (j = 0, wm = *wms; j < 3; j++, wm = wms[j]) {
+   seq_printf(m, "\tDumping %s watermarks, post vbl 
update: %s\n",
+  names[j], 
yesno(crtc_state->wm.need_postvbl_update));
+
+   for (i = 0; i < ARRAY_SIZE(wm->wm); i++) {
+   struct intel_wm_level *lvl = &wm->wm[i];
+
+   seq_printf(m, "\t\twm level[%i], enabled: %s, 
vals: %u, %u, %u, %u\n",
+ i, yesno(lvl->enable), lvl->pri_val,
+ lvl->spr_val, lvl->cur_val, 
lvl->fbc_val);
+   }
+
+   seq_printf(m, "\tLinetime: %u\n", wm->linetime);
+   seq_printf(m, "\tfbc wm enabled: %s, pipe: %s, sprites 
enabled: %s, scaled: %s\n",
+ yesno(wm->fbc_wm_enabled), 
yesno(wm->pipe_enabled),
+ yesno(wm->sprites_enabled), 
yesno(wm->sprites_scaled));
+   }
+   } else if (IS_VALLEYVIEW(dev_

[Intel-gfx] [PATCH] drm/i915/execlists: Remove the priority "optimisation"

2017-10-24 Thread Chris Wilson
Originally we set the priority to max upon inserting the request into
the execlists queue (and removing it from the scheduler lists). We could
then use the prio==INT_MAX as a shortcut within execlists_schedule() to
detect the end of the dependency chain. Since commit 1f181225f8ec
("drm/i915/execlists: Keep request->priority for its lifetime") this is
no longer true as we use the request completion as an indicator the
schedule dependency chain is complete instead. (This allows us to then
reschedule requests even when its context is in flight.) However, this
makes the GEM_BUG_ON() inside execlists_schedule() racy as we may change
the rq->prio at the same time. As the assertion is useful, let's keep
the assertion and remove the micro-optimisation.

Fixes: 1f181225f8ec ("drm/i915/execlists: Keep request->priority for its 
lifetime")
Signed-off-by: Chris Wilson 
Cc: Michał Winiarski 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_lrc.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 233c992a886b..c63960fee102 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -734,7 +734,6 @@ static void execlists_cancel_requests(struct 
intel_engine_cs *engine)
 
list_for_each_entry_safe(rq, rn, &p->requests, priotree.link) {
INIT_LIST_HEAD(&rq->priotree.link);
-   rq->priotree.priority = INT_MAX;
 
dma_fence_set_error(&rq->fence, -EIO);
__i915_gem_request_submit(rq);
@@ -891,7 +890,6 @@ static void intel_lrc_irq_handler(unsigned long data)
execlists_context_status_change(rq, 
INTEL_CONTEXT_SCHEDULE_OUT);
 
trace_i915_gem_request_out(rq);
-   rq->priotree.priority = INT_MAX;
i915_gem_request_put(rq);
 
execlists_port_complete(execlists, port);
-- 
2.15.0.rc1

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


[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/1] drm/i915: Save PM interrupt register offsets in device info

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

Series: series starting with [v2,1/1] drm/i915: Save PM interrupt register 
offsets in device info
URL   : https://patchwork.freedesktop.org/series/32526/
State : success

== Summary ==

Series 32526v1 series starting with [v2,1/1] drm/i915: Save PM interrupt 
register offsets in device info
https://patchwork.freedesktop.org/api/1.0/series/32526/revisions/1/mbox/

Test drv_module_reload:
Subgroup basic-no-display:
dmesg-warn -> INCOMPLETE (fi-cfl-s) fdo#103206

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:447s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:451s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:370s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:518s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:262s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:494s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:503s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:498s
fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
time:486s
fi-cfl-s total:287  pass:253  dwarn:2   dfail:0   fail:0   skip:31 
fi-cnl-y total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:635s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:422s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:251s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:581s
fi-glk-dsi   total:289  pass:258  dwarn:0   dfail:0   fail:1   skip:30  
time:492s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:453s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:428s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:434s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:491s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:460s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:491s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:572s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:477s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:588s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:544s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:455s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:646s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:519s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:503s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:451s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:565s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:421s

5c82a37eff83ab4e60e760fbaf03db5ba0563497 drm-tip: 2017y-10m-23d-18h-06m-28s UTC 
integration manifest
21074be0b1a8 drm/i915: Save PM interrupt register offsets in device info

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6155/
___
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/kms_atomic_transition: Make tests pass

2017-10-24 Thread Petri Latvala
On Mon, Oct 23, 2017 at 12:15:34PM +0200, Maarten Lankhorst wrote:
> Op 23-10-17 om 11:35 schreef Petri Latvala:
> >
> >
> > On Fri, Oct 20, 2017 at 03:24:15PM +0200, Maarten Lankhorst wrote:
> >
> > Subject: [Intel-gfx] [PATCH i-g-t] tests/kms_atomic_transition: Make tests 
> > pass
> >
> >
> > You have an excellent explanation of what this patch does in the long
> > description, and yet this short description says nothing of value.
> >
> >
> >
> Is this patch good with subject: 'tests/kms_atomic_transition: Do not update 
> unbound planes'?
> 

LGTM.

Explain the change of making fd_completed() call conditional too in
the commit message and

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


Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for igt/kms_rotation_crc: Add horizontal flip subtest. (rev2)

2017-10-24 Thread Arkadiusz Hiler
On Fri, Oct 20, 2017 at 11:48:02PM +, Patchwork wrote:
> == Series Details ==
> 
> Series: igt/kms_rotation_crc: Add horizontal flip subtest. (rev2)
> URL   : https://patchwork.freedesktop.org/series/31407/
> State : warning
> 
> == Summary ==
> 
> IGT patchset tested on top of latest successful build
> 9ba736aecc2a3cb34a2aeec8d417f66390e0c82b tools/intel_vbt_decode: abstract 
> child devices printing more
> 
> with latest DRM-Tip kernel build CI_DRM_3271
> 0760516f3127 drm-tip: 2017y-10m-20d-18h-40m-36s UTC integration manifest
> 
> Testlist changes:
> +igt@kms_rotation_crc@primary-x-tiled-reflect-x-0
> +igt@kms_rotation_crc@primary-x-tiled-reflect-x-0-flip
> +igt@kms_rotation_crc@primary-x-tiled-reflect-x-180
> +igt@kms_rotation_crc@primary-x-tiled-reflect-x-180-flip
> +igt@kms_rotation_crc@primary-yf-tiled-reflect-x-0
> +igt@kms_rotation_crc@primary-yf-tiled-reflect-x-0-flip
> +igt@kms_rotation_crc@primary-yf-tiled-reflect-x-90
> +igt@kms_rotation_crc@primary-yf-tiled-reflect-x-90-flip
> +igt@kms_rotation_crc@primary-yf-tiled-reflect-x-180
> +igt@kms_rotation_crc@primary-yf-tiled-reflect-x-180-flip
> +igt@kms_rotation_crc@primary-yf-tiled-reflect-x-270
> +igt@kms_rotation_crc@primary-yf-tiled-reflect-x-270-flip
> +igt@kms_rotation_crc@primary-y-tiled-reflect-x-0
> +igt@kms_rotation_crc@primary-y-tiled-reflect-x-0-flip
> +igt@kms_rotation_crc@primary-y-tiled-reflect-x-90
> +igt@kms_rotation_crc@primary-y-tiled-reflect-x-90-flip
> +igt@kms_rotation_crc@primary-y-tiled-reflect-x-180
> +igt@kms_rotation_crc@primary-y-tiled-reflect-x-180-flip
> +igt@kms_rotation_crc@primary-y-tiled-reflect-x-270
> +igt@kms_rotation_crc@primary-y-tiled-reflect-x-270-flip
> 
> Test chamelium:
> Subgroup dp-hpd-fast:
> incomplete -> SKIP   (fi-bdw-gvtdvm) fdo#102332
> Subgroup dp-crc-fast:
> fail   -> PASS   (fi-kbl-7500u) fdo#102514
> Test kms_pipe_crc_basic:
> Subgroup suspend-read-crc-pipe-b:
> pass   -> DMESG-WARN (fi-byt-j1900) fdo#101705
> Test drv_module_reload:
> Subgroup basic-reload-inject:
> pass   -> DMESG-WARN (fi-skl-6770hq)

Looks like a false positive from a known offender. I've scheduled a
rerun.

Cheers,
Arek

> fdo#102332 https://bugs.freedesktop.org/show_bug.cgi?id=102332
> fdo#102514 https://bugs.freedesktop.org/show_bug.cgi?id=102514
> fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705
> 
> fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
> time:442s
> fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
> time:455s
> fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
> time:378s
> fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
> time:525s
> fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
> time:265s
> fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
> time:507s
> fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
> time:499s
> fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
> time:499s
> fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
> time:484s
> fi-cfl-s total:289  pass:253  dwarn:4   dfail:0   fail:0   skip:32  
> time:558s
> fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
> time:414s
> fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
> time:255s
> fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
> time:582s
> fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
> time:450s
> fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
> time:426s
> fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
> time:437s
> fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
> time:497s
> fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
> time:459s
> fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
> time:495s
> fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
> time:571s
> fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
> time:478s
> fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
> time:585s
> fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
> time:549s
> fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
> time:456s
> fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
> time:647s
> fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
> time:517s
> fi-skl-6770hqtotal:289  pass:268  dwarn:1   dfail:0   fail:0   skip:20  
> time:501s
> fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
>

Re: [Intel-gfx] [PATCH i-g-t] run-tests.sh: Use piglit names when listing available tests

2017-10-24 Thread Arkadiusz Hiler
On Tue, Oct 24, 2017 at 01:40:21PM +0300, Petri Latvala wrote:
> List the available tests with piglit instead of by hand. This solves
> naming inconsistencies (piglit throwing caps away) as seen by
> cibuglog, and makes the listing code simpler.
> 
> The format of the listing changes from
> 
>  test-binary/subtest-name
> 
> to
> 
>  igt@test-binary@subtest-name

The exact conversion is currently done by CI scripts as well.
Judging from the substitution I think this will end up as igt@igt@...
Let's see in which funny way this will blow up and then let's fix it.

Acked-by: Arkadiusz Hiler 

But please come talk to Tomi and me before merging this :-)

> but so far nothing has been able to directly consume run-tests.sh -l
> output. The piglit format is directly consumable by piglit --test-list, and 
> thus
> by run-tests.sh -T.
> 
> Signed-off-by: Petri Latvala 
> Cc: Tomi Sarvela 
> Cc: Arkadiusz Hiler 
> ---
> 
> This patch cannot be merged without explicit confirmation from Tomi
> and Arek that the CI side is ready for this. Today, this will break
> sharded runs.
> 
> 
> scripts/run-tests.sh | 22 ++
>  1 file changed, 6 insertions(+), 16 deletions(-)
> 
> diff --git a/scripts/run-tests.sh b/scripts/run-tests.sh
> index a28dd876..acd2ae2f 100755
> --- a/scripts/run-tests.sh
> +++ b/scripts/run-tests.sh
> @@ -40,8 +40,6 @@ if [ ! -f "$IGT_TEST_ROOT/test-list.txt" ]; then
>   exit 1
>  fi
>  
> -TEST_LIST=`cat "$IGT_TEST_ROOT/test-list.txt" | sed -e '/TESTLIST/d' -e 's/ 
> /\n/g'`
> -
>  function download_piglit {
>   git clone git://anongit.freedesktop.org/piglit "$ROOT/piglit"
>  }
> @@ -70,24 +68,11 @@ function print_help {
>   echo "Useful patterns for test filtering are described in the API 
> documentation."
>  }
>  
> -function list_tests {
> - for test in $TEST_LIST; do
> - SUBTESTS=`"$IGT_TEST_ROOT/$test" --list-subtests`
> - if [ -z "$SUBTESTS" ]; then
> - echo "$test"
> - else
> - for subtest in $SUBTESTS; do
> - echo "$test/$subtest"
> - done
> - fi
> - done
> -}
> -
>  while getopts ":dhlr:st:T:vx:Rn" opt; do
>   case $opt in
>   d) download_piglit; exit ;;
>   h) print_help; exit ;;
> - l) list_tests; exit ;;
> + l) LIST_TESTS="true" ;;
>   r) RESULTS="$OPTARG" ;;
>   s) SUMMARY="html" ;;
>   t) FILTER="$FILTER -t $OPTARG" ;;
> @@ -125,6 +110,11 @@ if [ ! -x "$PIGLIT" ]; then
>   exit 1
>  fi
>  
> +if [ "x$LIST_TESTS" != "x" ]; then
> + IGT_TEST_ROOT="$IGT_TEST_ROOT" IGT_CONFIG_PATH="$IGT_CONFIG_PATH" 
> "$PIGLIT" print-cmd --format "{name}" igt
> + exit
> +fi
> +
>  if [ "x$RESUME" != "x" ]; then
>   sudo IGT_TEST_ROOT="$IGT_TEST_ROOT" IGT_CONFIG_PATH="$IGT_CONFIG_PATH" 
> "$PIGLIT" resume "$RESULTS" $NORETRY
>  else
> -- 
> 2.14.1
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915/execlists: Remove the priority "optimisation"

2017-10-24 Thread Michał Winiarski
On Tue, Oct 24, 2017 at 12:55:01PM +0100, Chris Wilson wrote:
> Originally we set the priority to max upon inserting the request into
> the execlists queue (and removing it from the scheduler lists). We could
> then use the prio==INT_MAX as a shortcut within execlists_schedule() to
> detect the end of the dependency chain. Since commit 1f181225f8ec
> ("drm/i915/execlists: Keep request->priority for its lifetime") this is
> no longer true as we use the request completion as an indicator the
> schedule dependency chain is complete instead. (This allows us to then
> reschedule requests even when its context is in flight.) However, this
> makes the GEM_BUG_ON() inside execlists_schedule() racy as we may change
> the rq->prio at the same time. As the assertion is useful, let's keep
> the assertion and remove the micro-optimisation.
> 
> Fixes: 1f181225f8ec ("drm/i915/execlists: Keep request->priority for its 
> lifetime")
> Signed-off-by: Chris Wilson 
> Cc: Michał Winiarski 
> Cc: Joonas Lahtinen 

Reviewed-by: Michał Winiarski 

-Michał

> ---
>  drivers/gpu/drm/i915/intel_lrc.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 233c992a886b..c63960fee102 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -734,7 +734,6 @@ static void execlists_cancel_requests(struct 
> intel_engine_cs *engine)
>  
>   list_for_each_entry_safe(rq, rn, &p->requests, priotree.link) {
>   INIT_LIST_HEAD(&rq->priotree.link);
> - rq->priotree.priority = INT_MAX;
>  
>   dma_fence_set_error(&rq->fence, -EIO);
>   __i915_gem_request_submit(rq);
> @@ -891,7 +890,6 @@ static void intel_lrc_irq_handler(unsigned long data)
>   execlists_context_status_change(rq, 
> INTEL_CONTEXT_SCHEDULE_OUT);
>  
>   trace_i915_gem_request_out(rq);
> - rq->priotree.priority = INT_MAX;
>   i915_gem_request_put(rq);
>  
>   execlists_port_complete(execlists, port);
> -- 
> 2.15.0.rc1
> 
___
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/huc: Use helper function while waiting for DMA completion

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

Series: drm/i915/huc: Use helper function while waiting for DMA completion
URL   : https://patchwork.freedesktop.org/series/32528/
State : failure

== Summary ==

Series 32528v1 drm/i915/huc: Use helper function while waiting for DMA 
completion
https://patchwork.freedesktop.org/api/1.0/series/32528/revisions/1/mbox/

Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-a:
pass   -> INCOMPLETE (fi-glk-1)

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:442s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:450s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:368s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:513s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:264s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:496s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:494s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:492s
fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
time:476s
fi-cfl-s total:289  pass:253  dwarn:4   dfail:0   fail:0   skip:32  
time:551s
fi-cnl-y total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:593s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:419s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:250s
fi-glk-1 total:239  pass:212  dwarn:0   dfail:0   fail:0   skip:26 
fi-glk-dsi   total:289  pass:258  dwarn:0   dfail:0   fail:1   skip:30  
time:491s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:430s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:427s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:431s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:493s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:456s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:493s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:569s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:472s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:579s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:540s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:459s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:641s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:517s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:504s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:453s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:562s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:423s

5c82a37eff83ab4e60e760fbaf03db5ba0563497 drm-tip: 2017y-10m-23d-18h-06m-28s UTC 
integration manifest
e071ef7ddca3 drm/i915/huc: Use helper function while waiting for DMA completion

== Logs ==

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


Re: [Intel-gfx] [PATCH i-g-t 1/2] meson: don't assume xmlrpc-c-config is there

2017-10-24 Thread Arkadiusz Hiler
On Tue, Oct 24, 2017 at 11:14:14AM +0300, Jani Nikula wrote:
> xmlrpc is an optional dependency. If pkg-config can't find it, don't
> assume xmlrpc-c-config will be there either. Make xmlrpc-c-config
> optional too.
> 
> Fixes error:
> 
> Meson encountered an error in file meson.build, line 73, column 1:
> Program or command 'xmlrpc-c-config' not foundor not executable
> 
> Fixes: 892abc602a8a ("meson: Add fallback for xmlrpc discovery")
> Cc: Arkadiusz Hiler 
> Signed-off-by: Jani Nikula 

Both patches are:

Reviewed-by: Arkadiusz Hiler 
and pushed. Thanks!


> ---
> 
> Note: Untested in the scenario described in 892abc602a8a ("meson: Add
> fallback for xmlrpc discovery")
> ---
>  meson.build | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/meson.build b/meson.build
> index ac991c2f9bf2..fb81c4dbbd55 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -69,9 +69,10 @@ xmlrpc = dependency('xmlrpc', required : false)
>  xmlrpc_util = dependency('xmlrpc_util', required : false)
>  xmlrpc_client = dependency('xmlrpc_client', required : false)
>  
> -if not xmlrpc.found()
> - libs_cmd = run_command('xmlrpc-c-config', 'client', '--libs')
> - cflags_cmd = run_command('xmlrpc-c-config', 'client', '--cflags')
> +xmlrpc_cmd = find_program('xmlrpc-c-config', required : false)
> +if not xmlrpc.found() and xmlrpc_cmd.found()
> + libs_cmd = run_command(xmlrpc_cmd, 'client', '--libs')
> + cflags_cmd = run_command(xmlrpc_cmd, 'client', '--cflags')
>  
>   if libs_cmd.returncode() == 0 and cflags_cmd.returncode() == 0
>   xmlrpc = declare_dependency(compile_args: 
> cflags_cmd.stdout().strip().split(),
> -- 
> 2.11.0
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH] drm/i915/gvt: Use common error handling code in shadow_workload_ring_buffer()

2017-10-24 Thread SF Markus Elfring
From: Markus Elfring 
Date: Tue, 24 Oct 2017 14:20:06 +0200

Add a jump target so that a call of the function "gvt_vgpu_err" is stored
only once at the end of this function implementation.
Replace two calls by goto statements.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/i915/gvt/cmd_parser.c | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.c 
b/drivers/gpu/drm/i915/gvt/cmd_parser.c
index 2c0ccbb817dc..caa181380958 100644
--- a/drivers/gpu/drm/i915/gvt/cmd_parser.c
+++ b/drivers/gpu/drm/i915/gvt/cmd_parser.c
@@ -2640,10 +2640,9 @@ static int shadow_workload_ring_buffer(struct 
intel_vgpu_workload *workload)
if (gma_head > gma_tail) {
ret = copy_gma_to_hva(vgpu, vgpu->gtt.ggtt_mm,
  gma_head, gma_top, shadow_ring_buffer_va);
-   if (ret < 0) {
-   gvt_vgpu_err("fail to copy guest ring buffer\n");
-   return ret;
-   }
+   if (ret < 0)
+   goto report_failure;
+
shadow_ring_buffer_va += ret;
gma_head = workload->rb_start;
}
@@ -2651,11 +2650,14 @@ static int shadow_workload_ring_buffer(struct 
intel_vgpu_workload *workload)
/* copy head or start <-> tail */
ret = copy_gma_to_hva(vgpu, vgpu->gtt.ggtt_mm, gma_head, gma_tail,
shadow_ring_buffer_va);
-   if (ret < 0) {
-   gvt_vgpu_err("fail to copy guest ring buffer\n");
-   return ret;
-   }
+   if (ret < 0)
+   goto report_failure;
+
return 0;
+
+report_failure:
+   gvt_vgpu_err("fail to copy guest ring buffer\n");
+   return ret;
 }
 
 int intel_gvt_scan_and_shadow_ringbuffer(struct intel_vgpu_workload *workload)
-- 
2.14.3

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


Re: [Intel-gfx] [PATCH i-g-t] lib/igt_kms: Only print changed mode objects during atomic commit.

2017-10-24 Thread Petri Latvala
On Fri, Oct 20, 2017 at 03:23:57PM +0200, Maarten Lankhorst wrote:
> When we only print mode objects that have changed properties, we
> reduce a lot of the spam. Fortuantely we have a single bitfield
> now that gets printed when something is changed. Use that to decrease
> the amount of spam.


s/Fortuantely/Fortunately/


> 
> Signed-off-by: Maarten Lankhorst 

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


Re: [Intel-gfx] [PATCH i-g-t] run-tests.sh: Use piglit names when listing available tests

2017-10-24 Thread Tomi Sarvela

On 24/10/17 15:18, Arkadiusz Hiler wrote:

On Tue, Oct 24, 2017 at 01:40:21PM +0300, Petri Latvala wrote:

List the available tests with piglit instead of by hand. This solves
naming inconsistencies (piglit throwing caps away) as seen by
cibuglog, and makes the listing code simpler.

The format of the listing changes from

  test-binary/subtest-name

to

  igt@test-binary@subtest-name


The exact conversion is currently done by CI scripts as well.
Judging from the substitution I think this will end up as igt@igt@...
Let's see in which funny way this will blow up and then let's fix it.

Acked-by: Arkadiusz Hiler 

But please come talk to Tomi and me before merging this :-)


Already fixed in the scripts (not extensively tested, though..)
They can eat either format (test/subtest or igt@test@subtest).

Tomi




but so far nothing has been able to directly consume run-tests.sh -l
output. The piglit format is directly consumable by piglit --test-list, and thus
by run-tests.sh -T.

Signed-off-by: Petri Latvala 
Cc: Tomi Sarvela 
Cc: Arkadiusz Hiler 
---

This patch cannot be merged without explicit confirmation from Tomi
and Arek that the CI side is ready for this. Today, this will break
sharded runs.


scripts/run-tests.sh | 22 ++
  1 file changed, 6 insertions(+), 16 deletions(-)

diff --git a/scripts/run-tests.sh b/scripts/run-tests.sh
index a28dd876..acd2ae2f 100755
--- a/scripts/run-tests.sh
+++ b/scripts/run-tests.sh
@@ -40,8 +40,6 @@ if [ ! -f "$IGT_TEST_ROOT/test-list.txt" ]; then
exit 1
  fi
  
-TEST_LIST=`cat "$IGT_TEST_ROOT/test-list.txt" | sed -e '/TESTLIST/d' -e 's/ /\n/g'`

-
  function download_piglit {
git clone git://anongit.freedesktop.org/piglit "$ROOT/piglit"
  }
@@ -70,24 +68,11 @@ function print_help {
echo "Useful patterns for test filtering are described in the API 
documentation."
  }
  
-function list_tests {

-   for test in $TEST_LIST; do
-   SUBTESTS=`"$IGT_TEST_ROOT/$test" --list-subtests`
-   if [ -z "$SUBTESTS" ]; then
-   echo "$test"
-   else
-   for subtest in $SUBTESTS; do
-   echo "$test/$subtest"
-   done
-   fi
-   done
-}
-
  while getopts ":dhlr:st:T:vx:Rn" opt; do
case $opt in
d) download_piglit; exit ;;
h) print_help; exit ;;
-   l) list_tests; exit ;;
+   l) LIST_TESTS="true" ;;
r) RESULTS="$OPTARG" ;;
s) SUMMARY="html" ;;
t) FILTER="$FILTER -t $OPTARG" ;;
@@ -125,6 +110,11 @@ if [ ! -x "$PIGLIT" ]; then
exit 1
  fi
  
+if [ "x$LIST_TESTS" != "x" ]; then

+   IGT_TEST_ROOT="$IGT_TEST_ROOT" IGT_CONFIG_PATH="$IGT_CONFIG_PATH" "$PIGLIT" 
print-cmd --format "{name}" igt
+   exit
+fi
+
  if [ "x$RESUME" != "x" ]; then
sudo IGT_TEST_ROOT="$IGT_TEST_ROOT" IGT_CONFIG_PATH="$IGT_CONFIG_PATH" "$PIGLIT" 
resume "$RESULTS" $NORETRY
  else
--
2.14.1




Tomi
--
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] drm/i915/cnl: Get RC6 working.

2017-10-24 Thread David Weinehall
On Mon, Oct 23, 2017 at 03:46:12PM -0700, Rodrigo Vivi wrote:
> On CNL, individual wake rate limit was added to each engine.
> 
> GT can only go to RC6 if both Render and Media engines are
> individually qualified. So we need to set their individual
> wake rate limit.
> 
> +-+---+--+--+
> | |GT RC6 |  Render C6   |   Media C6   |
> +-+---+--+--+
> | Wake rate limit | 0xA09C[31:16] | 0xA09C[15:0] | 0xA0A0[15:0] |
> +-+---+--+--+
> 
> v2: - Tune Render and Media wake rate values according to some extra
>   info I got from HW engineers. Value can be tuned, but for now
>   these are the recommended values.
> - Fix typos pointed by James.
> 
> Cc: Nathan Ciobanu 
> Cc: Wayne Boyer 
> Cc: Joe Konno 
> Cc: David Weinehall 
> Signed-off-by: Rodrigo Vivi 
> Reviewed-by: James Ausmus 

I've verified that RC6 works with your patch applied.
Minor comments below, but nothing major. Great work!


Reviewed-by: David Weinehall 

> ---
>  drivers/gpu/drm/i915/i915_reg.h |  1 +
>  drivers/gpu/drm/i915/intel_pm.c | 15 +++
>  2 files changed, 12 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 68a58cce6ab1..f138eae82bf0 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7905,6 +7905,7 @@ enum {
>  #define GEN6_RC1_WAKE_RATE_LIMIT _MMIO(0xA098)
>  #define GEN6_RC6_WAKE_RATE_LIMIT _MMIO(0xA09C)
>  #define GEN6_RC6pp_WAKE_RATE_LIMIT   _MMIO(0xA0A0)
> +#define GEN10_MEDIA_WAKE_RATE_LIMIT  _MMIO(0xA0A0)
>  #define GEN6_RC_EVALUATION_INTERVAL  _MMIO(0xA0A8)
>  #define GEN6_RC_IDLE_HYSTERSIS   _MMIO(0xA0AC)
>  #define GEN6_RC_SLEEP_MMIO(0xA0B0)
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 5fdae39b1969..742d5455b201 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -6605,12 +6605,19 @@ static void gen9_enable_rc6(struct drm_i915_private 
> *dev_priv)
>   I915_WRITE(GEN6_RC_CONTROL, 0);
>  
>   /* 2b: Program RC6 thresholds.*/
> -
> - /* WaRsDoubleRc6WrlWithCoarsePowerGating: Doubling WRL only when CPG is 
> enabled */
> - if (IS_SKYLAKE(dev_priv))
> + if (INTEL_GEN(dev_priv) >= 10) {
> + I915_WRITE(GEN6_RC6_WAKE_RATE_LIMIT, 54 << 16 | 85);
> + I915_WRITE(GEN10_MEDIA_WAKE_RATE_LIMIT, 150);
> + } else if (IS_SKYLAKE(dev_priv)) {

How about:

} else if (NEEDS_WaRsDisableCoarsePowerGating(dev_priv)) {

I realise that this isn't code you're introducing, but fixing it at the
same time might make sense. We have a few other cases elsewhere with
where we apply Coarse PG even though (at least according to that
WA-test) we only need it on some Skylakes.

> + /*
> +  * WaRsDoubleRc6WrlWithCoarsePowerGating:skl Doubling WRL only
> +  * when CPG is enabled
> +  */
>   I915_WRITE(GEN6_RC6_WAKE_RATE_LIMIT, 108 << 16);
> - else
> + } else {
>   I915_WRITE(GEN6_RC6_WAKE_RATE_LIMIT, 54 << 16);
> + }
> +
>   I915_WRITE(GEN6_RC_EVALUATION_INTERVAL, 125000); /* 12500 * 1280ns */
>   I915_WRITE(GEN6_RC_IDLE_HYSTERSIS, 25); /* 25 * 1280ns */
>   for_each_engine(engine, dev_priv, id)
> -- 
> 2.13.5
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915/gvt: Use common error handling code in shadow_workload_ring_buffer()

2017-10-24 Thread Jani Nikula
On Tue, 24 Oct 2017, SF Markus Elfring  wrote:
> From: Markus Elfring 
> Date: Tue, 24 Oct 2017 14:20:06 +0200
>
> Add a jump target so that a call of the function "gvt_vgpu_err" is stored
> only once at the end of this function implementation.
> Replace two calls by goto statements.
>
> This issue was detected by using the Coccinelle software.

I don't think this is an issue or an improvement.

BR,
Jani.

>
> Signed-off-by: Markus Elfring 
> ---
>  drivers/gpu/drm/i915/gvt/cmd_parser.c | 18 ++
>  1 file changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.c 
> b/drivers/gpu/drm/i915/gvt/cmd_parser.c
> index 2c0ccbb817dc..caa181380958 100644
> --- a/drivers/gpu/drm/i915/gvt/cmd_parser.c
> +++ b/drivers/gpu/drm/i915/gvt/cmd_parser.c
> @@ -2640,10 +2640,9 @@ static int shadow_workload_ring_buffer(struct 
> intel_vgpu_workload *workload)
>   if (gma_head > gma_tail) {
>   ret = copy_gma_to_hva(vgpu, vgpu->gtt.ggtt_mm,
> gma_head, gma_top, shadow_ring_buffer_va);
> - if (ret < 0) {
> - gvt_vgpu_err("fail to copy guest ring buffer\n");
> - return ret;
> - }
> + if (ret < 0)
> + goto report_failure;
> +
>   shadow_ring_buffer_va += ret;
>   gma_head = workload->rb_start;
>   }
> @@ -2651,11 +2650,14 @@ static int shadow_workload_ring_buffer(struct 
> intel_vgpu_workload *workload)
>   /* copy head or start <-> tail */
>   ret = copy_gma_to_hva(vgpu, vgpu->gtt.ggtt_mm, gma_head, gma_tail,
>   shadow_ring_buffer_va);
> - if (ret < 0) {
> - gvt_vgpu_err("fail to copy guest ring buffer\n");
> - return ret;
> - }
> + if (ret < 0)
> + goto report_failure;
> +
>   return 0;
> +
> +report_failure:
> + gvt_vgpu_err("fail to copy guest ring buffer\n");
> + return ret;
>  }
>  
>  int intel_gvt_scan_and_shadow_ringbuffer(struct intel_vgpu_workload 
> *workload)

-- 
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 v2] drm-auth

2017-10-24 Thread Chris Wilson
---
 drivers/gpu/drm/drm_auth.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index 4c14b2cbc733..c40e603e0559 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -285,7 +285,8 @@ void drm_master_release(struct drm_file *file_priv)
if (dev->master == file_priv->master)
drm_drop_master(dev, file_priv);
 out:
-   if (file_priv->is_master) {
+   if (drm_core_check_feature(dev, DRIVER_MODESET) &&
+   file_priv->is_master) {
/* Revoke any leases held by this or lessees, but only if
 * this is the "real" master
 */
-- 
2.15.0.rc1

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


[Intel-gfx] [PATCH igt v2] igt/gem_ctx_isolation: Check isolation of registers between contexts

2017-10-24 Thread Chris Wilson
A new context assumes that all of its registers are in the default state
when it is created. What may happen is that a register written by one
context may leak into the second, causing mass confusion.

Signed-off-by: Chris Wilson 
---
 tests/Makefile.sources|   1 +
 tests/gem_ctx_isolation.c | 650 ++
 2 files changed, 651 insertions(+)
 create mode 100644 tests/gem_ctx_isolation.c

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index ac9f90bc..d18b7461 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -57,6 +57,7 @@ TESTS_progs = \
gem_ctx_basic \
gem_ctx_create \
gem_ctx_exec \
+   gem_ctx_isolation \
gem_ctx_param \
gem_ctx_switch \
gem_ctx_thrash \
diff --git a/tests/gem_ctx_isolation.c b/tests/gem_ctx_isolation.c
new file mode 100644
index ..0bbc2279
--- /dev/null
+++ b/tests/gem_ctx_isolation.c
@@ -0,0 +1,650 @@
+/*
+ * 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 "igt.h"
+#include "igt_dummyload.h"
+
+#define MAX_REG 0x4
+#define NUM_REGS (MAX_REG / sizeof(uint32_t))
+
+#define PAGE_ALIGN(x) ALIGN(x, 4096)
+
+#define DIRTY 0x1
+#define UNSAFE 0x2
+
+enum {
+   RCS_MASK = 0x1,
+   BCS_MASK = 0x2,
+   VCS_MASK = 0x4,
+   VECS_MASK = 0x8,
+};
+
+#define ALL ~0u
+#define GEN_RANGE(x, y) ((ALL >> (32 - (y - x + 1))) << x)
+
+#define LAST_KNOWN_GEN 10
+
+static const struct named_register {
+   const char *name;
+   unsigned int gen_mask;
+   unsigned int engine_mask;
+   uint32_t offset;
+} safe_registers[] = {
+   { "NOPID", ALL, RCS_MASK, 0x2094 },
+   { "MI_PREDICATE_RESULT_2", ALL, RCS_MASK, 0x23bc },
+   { "INSTPM", ALL, RCS_MASK, 0x20c0 },
+   { "IA_VERTICES_COUNT (low)", ALL, RCS_MASK, 0x2310 },
+   { "IA_VERTICES_COUNT (high)", ALL, RCS_MASK, 0x2314 },
+   { "IA_PRIMITIVES_COUNT (low)", ALL, RCS_MASK, 0x2318 },
+   { "IA_PRIMITIVES_COUNT (high)", ALL, RCS_MASK, 0x231c },
+   { "VS_INVOCATION_COUNT (low)", ALL, RCS_MASK, 0x2320 },
+   { "VS_INVOCATION_COUNT (high)", ALL, RCS_MASK, 0x2324 },
+   { "HS_INVOCATION_COUNT (low)", ALL, RCS_MASK, 0x2300 },
+   { "HS_INVOCATION_COUNT (high)", ALL, RCS_MASK, 0x2304 },
+   { "DS_INVOCATION_COUNT (low)", ALL, RCS_MASK, 0x2308 },
+   { "DS_INVOCATION_COUNT (high)", ALL, RCS_MASK, 0x230c },
+   { "GS_INVOCATION_COUNT (low)", ALL, RCS_MASK, 0x2328 },
+   { "GS_INVOCATION_COUNT (high)", ALL, RCS_MASK, 0x232c },
+   { "GS_PRIMITIVES_COUNT (low)", ALL, RCS_MASK, 0x2330 },
+   { "GS_PRIMITIVES_COUNT (high)", ALL, RCS_MASK, 0x2334 },
+   { "CL_INVOCATION_COUNT (low)", ALL, RCS_MASK, 0x2338 },
+   { "CL_INVOCATION_COUNT (high)", ALL, RCS_MASK, 0x233c },
+   { "CL_PRIMITIVES_COUNT (low)", ALL, RCS_MASK, 0x2340 },
+   { "CL_PRIMITIVES_COUNT (high)", ALL, RCS_MASK, 0x2344 },
+   { "PS_INVOCATION_COUNT_0 (low)", ALL, RCS_MASK, 0x22c8 },
+   { "PS_INVOCATION_COUNT_0 (high)", ALL, RCS_MASK, 0x22cc },
+   { "PS_DEPTH_COUNT_0 (low)", ALL, RCS_MASK, 0x22d8 },
+   { "PS_DEPTH_COUNT_0 (high)", ALL, RCS_MASK, 0x22dc },
+   { "GPUGPU_DISPATCHDIMX", ALL, RCS_MASK, 0x2500 },
+   { "GPUGPU_DISPATCHDIMY", ALL, RCS_MASK, 0x2504 },
+   { "GPUGPU_DISPATCHDIMZ", ALL, RCS_MASK, 0x2508 },
+   { "MI_PREDICATE_SRC0 (low)", ALL, RCS_MASK, 0x2400 },
+   { "MI_PREDICATE_SRC0 (high)", ALL, RCS_MASK, 0x2404 },
+   { "MI_PREDICATE_SRC1 (low)", ALL, RCS_MASK, 0x2408 },
+   { "MI_PREDICATE_SRC1 (high)", ALL, RCS_MASK, 0x240c },
+   { "MI_PREDICATE_DATA (low)", ALL, RCS_MASK, 0x2410 },
+   { "MI_PREDICATE_DATA (high)", ALL, RCS_MASK, 0x2414 },
+   { "MI_PRED_RESULT", ALL, RCS_MASK, 0x2418 },
+   { "3DPRIM_END_OFFSET", ALL, RCS_MASK, 0x2420 },
+   { "3DPRIM_START_VERTEX"

Re: [Intel-gfx] [PATCH 2/3] drm/i915/guc: Always enable the breadcrumbs irq

2017-10-24 Thread Michał Winiarski
On Fri, Oct 20, 2017 at 10:16:47PM +0100, Chris Wilson wrote:
> Quoting Chris Wilson (2017-10-20 22:06:39)
> > The execlists emulation on top of the GuC (used for scheduling and
> > preemption) depends on the MI_USER_INTERRUPT for its notifications and
> > tasklet action. As we always employ the irq, there is no advantage in
> > ever disabling it while we are using the GuC, so allow us to arm the
> > breadcrumb irq when enabling GuC submission and disarm upon disabling.
> > The impact should be lessened by the delayed irq disabling we do (we
> > only disable after receiving an interrupt for which no one was wanting),
> > but allowing guc to explicitly manage the irq in relation to itself is
> > simpler and prevents an issue with losing an interrupt for preemption
> > as it is not coupled to an active request.
> > 
> > Internally, we add a reference counter (breadcrumbs.irq_users) as a
> > simple mechanism to allow GuC to keep the breadcrumb irq enabled. It
> > also means that the missed-breadcrumb timer is permanently active.
> 
> Scratch that part; the timer is only enabled for waiters.
> -Chris

With additional note that as a consequence, we're basically postponing the
irq_disable until idle_work_handler.

Reviewed-by: Michał Winiarski 

-Michał

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


[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/1] drm/i915: Save PM interrupt register offsets in device info

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

Series: series starting with [v2,1/1] drm/i915: Save PM interrupt register 
offsets in device info
URL   : https://patchwork.freedesktop.org/series/32526/
State : success

== Summary ==

Test kms_busy:
Subgroup extended-modeset-hang-oldfb-with-reset-render-C:
pass   -> DMESG-WARN (shard-hsw) fdo#102249 +1
Test drv_module_reload:
Subgroup basic-reload-inject:
dmesg-warn -> PASS   (shard-hsw) fdo#102707
Test perf:
Subgroup polling:
fail   -> PASS   (shard-hsw) fdo#102252

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

shard-hswtotal:2540 pass:1433 dwarn:2   dfail:0   fail:8   skip:1097 
time:9224s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6155/shards.html
___
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: Dump watermark info in i915_display_info.

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

Series: drm/i915: Dump watermark info in i915_display_info.
URL   : https://patchwork.freedesktop.org/series/32532/
State : failure

== Summary ==

  CHK include/config/kernel.release
  CHK include/generated/uapi/linux/version.h
  CHK include/generated/utsrelease.h
  CHK include/generated/bounds.h
  CHK include/generated/timeconst.h
  CHK include/generated/asm-offsets.h
  CALLscripts/checksyscalls.sh
  CHK scripts/mod/devicetable-offsets.h
  CHK include/generated/compile.h
  CHK kernel/config_data.h
  CC [M]  drivers/gpu/drm/i915/i915_debugfs.o
drivers/gpu/drm/i915/i915_debugfs.c: In function ‘intel_watermark_info’:
drivers/gpu/drm/i915/i915_debugfs.c:3243:41: error: iteration 2 invokes 
undefined behavior [-Werror=aggressive-loop-optimizations]
   for (j = 0, wm = *wms; j < 3; j++, wm = wms[j]) {
  ~~~^~~~
drivers/gpu/drm/i915/i915_debugfs.c:3243:3: note: within this loop
   for (j = 0, wm = *wms; j < 3; j++, wm = wms[j]) {
   ^~~
drivers/gpu/drm/i915/i915_debugfs.c:3267:41: error: iteration 2 invokes 
undefined behavior [-Werror=aggressive-loop-optimizations]
   for (j = 0, wm = *wms; j < 3; j++, wm = wms[j]) {
  ~~~^~~~
drivers/gpu/drm/i915/i915_debugfs.c:3267:3: note: within this loop
   for (j = 0, wm = *wms; j < 3; j++, wm = wms[j]) {
   ^~~
drivers/gpu/drm/i915/i915_debugfs.c:3295:41: error: iteration 2 invokes 
undefined behavior [-Werror=aggressive-loop-optimizations]
   for (j = 0, wm = *wms; j < 3; j++, wm = wms[j]) {
  ~~~^~~~
drivers/gpu/drm/i915/i915_debugfs.c:3295:3: note: within this loop
   for (j = 0, wm = *wms; j < 3; j++, wm = wms[j]) {
   ^~~
cc1: all warnings being treated as errors
scripts/Makefile.build:313: recipe for target 
'drivers/gpu/drm/i915/i915_debugfs.o' failed
make[4]: *** [drivers/gpu/drm/i915/i915_debugfs.o] Error 1
scripts/Makefile.build:572: recipe for target 'drivers/gpu/drm/i915' failed
make[3]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:572: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:572: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:1023: recipe for target 'drivers' failed
make: *** [drivers] Error 2

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


[Intel-gfx] [PATCH] drm/i915: Dump watermark info in i915_display_info, v2.

2017-10-24 Thread Maarten Lankhorst
Dumping watermark info will make it easier to debug whether
the hardware watermarks match what's calculated for intermediate
and optimal watermarks. This has made it easier to debug certain
SNB underruns, so I've extended it from a hack to something that
will print all atomic watermarks.

Changes since v1:
- Fix WM assignment compiler warning.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 155 
 1 file changed, 155 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index c65e381b85f3..f9f9550137c3 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3170,6 +3170,160 @@ static void intel_scaler_info(struct seq_file *m, 
struct intel_crtc *intel_crtc)
}
 }
 
+static void intel_watermark_info(struct seq_file *m,
+struct drm_i915_private *dev_priv,
+struct intel_crtc *crtc)
+{
+   struct intel_crtc_state *crtc_state =
+   to_intel_crtc_state(crtc->base.state);
+   int i, j;
+   const char *names[3] = {
+   "hardware",
+   "intermediate",
+   "optimal"
+   };
+
+   if (INTEL_GEN(dev_priv) >= 9) {
+   struct skl_pipe_wm *wm = &crtc_state->wm.skl.optimal;
+   struct skl_ddb_entry *entry = &crtc_state->wm.skl.ddb;
+   struct skl_ddb_allocation *ddb = &dev_priv->wm.skl_hw.ddb;
+
+   seq_printf(m, "\tDDB allocation: start %u end %u, size %u\n",
+  entry->start, entry->end, skl_ddb_entry_size(entry));
+   for (i = 0; i < ARRAY_SIZE(ddb->plane[crtc->pipe]); i++) {
+   entry = &ddb->plane[crtc->pipe][i];
+
+   if (!skl_ddb_entry_size(entry))
+   continue;
+
+   seq_printf(m, "\t\tplane %d%c DDB allocation: start %u 
end %u, size %u, ",
+  i, pipe_name(crtc->pipe), entry->start, 
entry->end,
+  skl_ddb_entry_size(entry));
+
+   entry = &ddb->y_plane[crtc->pipe][i];
+   if (!skl_ddb_entry_size(entry))
+   continue;
+
+   seq_printf(m, "\t\tplane %d%c DDB Y allocation: start 
%u end %u, size %u, ",
+  i, pipe_name(crtc->pipe), entry->start, 
entry->end,
+  skl_ddb_entry_size(entry));
+   }
+
+   seq_printf(m, "\tLinetime: %u\n", wm->linetime);
+
+   for (i = 0; i < ARRAY_SIZE(wm->planes); i++) {
+   struct skl_plane_wm *pwm = &wm->planes[i];
+
+   seq_printf(m, "\tplane %d%c, wm enabled: %s",
+  i, pipe_name(crtc->pipe),
+  enableddisabled(pwm->wm[0].plane_en));
+   if (!pwm->wm[0].plane_en)
+   continue;
+
+   seq_printf(m, "\t\tTransition wm: %s, lines %u, blocks 
%u",
+  enableddisabled(pwm->trans_wm.plane_en),
+  pwm->trans_wm.plane_res_b, 
pwm->trans_wm.plane_res_l);
+
+   for (j = 0; j < ARRAY_SIZE(pwm->wm); j++) {
+   if (!pwm->wm[j].plane_en)
+   break;
+
+ seq_printf(m, "\t\tLevel[%u]: lines %u, 
blocks %u",
+j, pwm->trans_wm.plane_res_b,
+pwm->trans_wm.plane_res_l);
+   }
+   }
+   } else if (HAS_PCH_SPLIT(dev_priv)) {
+   struct intel_pipe_wm *wms[3] = {
+   &crtc->wm.active.ilk,
+   &crtc_state->wm.ilk.intermediate,
+   &crtc_state->wm.ilk.optimal };
+
+   for (j = 0; j < 3; j++) {
+   struct intel_pipe_wm *wm = wms[j];
+
+   seq_printf(m, "\tDumping %s watermarks, post vbl 
update: %s\n",
+  names[j], 
yesno(crtc_state->wm.need_postvbl_update));
+
+   for (i = 0; i < ARRAY_SIZE(wm->wm); i++) {
+   struct intel_wm_level *lvl = &wm->wm[i];
+
+   seq_printf(m, "\t\twm level[%i], enabled: %s, 
vals: %u, %u, %u, %u\n",
+ i, yesno(lvl->enable), lvl->pri_val,
+ lvl->spr_val, lvl->cur_val, 
lvl->fbc_val);
+   }
+
+   seq_printf(m, "\tLinetime: %u\n", wm->linetime);
+   seq_printf(m, "\tfbc wm enabled: %s, pipe: %s, sprites 
enabled: %s, scaled: %s\n",
+  

Re: [Intel-gfx] drm/i915/gvt: Use common error handling code in shadow_workload_ring_buffer()

2017-10-24 Thread SF Markus Elfring
>> Add a jump target so that a call of the function "gvt_vgpu_err" is stored
>> only once at the end of this function implementation.
>> Replace two calls by goto statements.
>>
>> This issue was detected by using the Coccinelle software.
> 
> I don't think this is an issue or an improvement.

Do you care for the detail how often an error message is stored in the code?

Regards,
Markus
___
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: CNL DVFS thing (rev7)

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

Series: drm/i915: CNL DVFS thing (rev7)
URL   : https://patchwork.freedesktop.org/series/32247/
State : failure

== Summary ==

Series 32247v7 drm/i915: CNL DVFS thing
https://patchwork.freedesktop.org/api/1.0/series/32247/revisions/7/mbox/

Test kms_cursor_legacy:
Subgroup basic-flip-after-cursor-legacy:
pass   -> INCOMPLETE (fi-kbl-7500u)

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:441s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:450s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:371s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:533s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:261s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:496s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:501s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:496s
fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
time:481s
fi-cfl-s total:289  pass:253  dwarn:4   dfail:0   fail:0   skip:32  
time:549s
fi-cnl-y total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:614s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:413s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:250s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:582s
fi-glk-dsi   total:289  pass:258  dwarn:0   dfail:0   fail:1   skip:30  
time:490s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:430s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:430s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:431s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:497s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:462s
fi-kbl-7500u total:212  pass:194  dwarn:1   dfail:0   fail:0   skip:16 
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:578s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:478s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:591s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:542s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:445s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:647s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:534s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:502s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:456s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:573s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:424s

5c82a37eff83ab4e60e760fbaf03db5ba0563497 drm-tip: 2017y-10m-23d-18h-06m-28s UTC 
integration manifest
79e92e64702f drm/i915: Perform a central cdclk state sanity check
4daf11cee53f drm/i915: Sanity check cdclk in vlv_set_cdclk()
eaafe95996e5 drm/i915: Adjust system agent voltage on CNL if required by DDI 
ports
2369a11b7117 drm/i915: Use cdclk_state->voltage on CNL
19680061ffe1 drm/i915: Use cdclk_state->voltage on BXT/GLK
7360a7ab6801 drm/i915: Use cdclk_state->voltage on SKL/KBL/CFL
1e3a3cbae375 drm/i915: Use cdclk_state->voltage on BDW
9cbcbfc9745e drm/i915: Use cdclk_state->voltage on VLV/CHV
ade92daa583d drm/i915: Start tracking voltage level in the cdclk state
df545f1cec2c drm/i915: Clean up some cdclk switch statements

== Logs ==

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


[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/execlists: Remove the priority "optimisation"

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

Series: drm/i915/execlists: Remove the priority "optimisation"
URL   : https://patchwork.freedesktop.org/series/32533/
State : success

== Summary ==

Series 32533v1 drm/i915/execlists: Remove the priority "optimisation"
https://patchwork.freedesktop.org/api/1.0/series/32533/revisions/1/mbox/

Test chamelium:
Subgroup dp-crc-fast:
pass   -> FAIL   (fi-kbl-7500u) fdo#102514
Test kms_frontbuffer_tracking:
Subgroup basic:
fail   -> INCOMPLETE (fi-glk-dsi)

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:442s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:445s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:370s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:526s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:261s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:497s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:494s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:489s
fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
time:474s
fi-cfl-s total:289  pass:253  dwarn:4   dfail:0   fail:0   skip:32  
time:556s
fi-cnl-y total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:602s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:423s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:250s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:578s
fi-glk-dsi   total:225  pass:198  dwarn:0   dfail:0   fail:0   skip:26 
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:430s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:426s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:439s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:484s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:460s
fi-kbl-7500u total:289  pass:263  dwarn:1   dfail:0   fail:1   skip:24  
time:483s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:575s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:477s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:584s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:552s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:458s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:645s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:522s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:500s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:462s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:559s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:418s

5c82a37eff83ab4e60e760fbaf03db5ba0563497 drm-tip: 2017y-10m-23d-18h-06m-28s UTC 
integration manifest
ff9cad6080d6 drm/i915/execlists: Remove the priority "optimisation"

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6159/
___
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-auth

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

Series: drm-auth
URL   : https://patchwork.freedesktop.org/series/32538/
State : failure

== Summary ==

Series 32538 revision 1 was fully merged or fully failed: no git log

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


Re: [Intel-gfx] drm/i915/gvt: Use common error handling code in shadow_workload_ring_buffer()

2017-10-24 Thread Garry Hurley
Markus, 

I normally keep quiet on threads like this. I half agree with you. Yes, perhaps 
a reportError function would be a good idea, but it seems that what you are 
suggesting is trading an inline subroutine call for a spaghetti-code vondition. 
The goto is used only if you do not have any code that follows, and what you 
are taking out is a function call that DOES return execution flow to the 
calling block. You are replacing it with a goto call which does not return 
execution flow. The risks of process termination during a goto call make it a 
bad idea. In this case, the subroutine call is the right move. If the reuse of 
the error message bothers you, perhaps it is a good candidate for a static 
string definition, so that if it is changed it can be changed in one location 
in the code. The tradeoff there is that the static string definition will eat a 
few bytes of memory from the variable storage. Just my perspective. I could be 
wrong. 

Sent from my iPhone

On Oct 24, 2017, at 9:17 AM, SF Markus Elfring  
wrote:

>>> Add a jump target so that a call of the function "gvt_vgpu_err" is stored
>>> only once at the end of this function implementation.
>>> Replace two calls by goto statements.
>>> 
>>> This issue was detected by using the Coccinelle software.
>> 
>> I don't think this is an issue or an improvement.
> 
> Do you care for the detail how often an error message is stored in the code?
> 
> Regards,
> Markus
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 0/2] GPU-DRM-i915-DP: Fine-tuning for two function implementations

2017-10-24 Thread SF Markus Elfring
From: Markus Elfring 
Date: Tue, 24 Oct 2017 15:54:32 +0200

Two update suggestions were taken into account
from static source code analysis.

Markus Elfring (2):
  Delete an unnecessary goto statement in intel_dp_sink_crc()
  Use common error handling code in intel_dp_sink_crc_stop()

 drivers/gpu/drm/i915/intel_dp.c | 34 +++---
 1 file changed, 15 insertions(+), 19 deletions(-)

-- 
2.14.3

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


[Intel-gfx] [PATCH 1/2] drm/i915/dp: Delete an unnecessary goto statement in intel_dp_sink_crc()

2017-10-24 Thread SF Markus Elfring
From: Markus Elfring 
Date: Tue, 24 Oct 2017 15:15:20 +0200

A jump was specified for a location which was directly behind.
Thus remove such an unnecessary goto statement.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/i915/intel_dp.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index ca48bce23a6f..342f1a1fa085 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3994,10 +3994,8 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, u8 *crc)
goto stop;
}
 
-   if (drm_dp_dpcd_read(&intel_dp->aux, DP_TEST_CRC_R_CR, crc, 6) < 0) {
+   if (drm_dp_dpcd_read(&intel_dp->aux, DP_TEST_CRC_R_CR, crc, 6) < 0)
ret = -EIO;
-   goto stop;
-   }
 
 stop:
intel_dp_sink_crc_stop(intel_dp);
-- 
2.14.3

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


[Intel-gfx] [PATCH 2/2] drm/i915/dp: Use common error handling code in intel_dp_sink_crc_stop()

2017-10-24 Thread SF Markus Elfring
From: Markus Elfring 
Date: Tue, 24 Oct 2017 15:40:47 +0200

Adjust jump targets so that a specific error code assignment
will be in the implementation only at the end of this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/gpu/drm/i915/intel_dp.c | 30 ++
 1 file changed, 14 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 342f1a1fa085..3dd514a77008 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3894,27 +3894,19 @@ static int intel_dp_sink_crc_stop(struct intel_dp 
*intel_dp)
int count = 0;
int attempts = 10;
 
-   if (drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_SINK, &buf) < 0) {
-   DRM_DEBUG_KMS("Sink CRC couldn't be stopped properly\n");
-   ret = -EIO;
-   goto out;
-   }
+   if (drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_SINK, &buf) < 0)
+   goto report_failure;
 
if (drm_dp_dpcd_writeb(&intel_dp->aux, DP_TEST_SINK,
-  buf & ~DP_TEST_SINK_START) < 0) {
-   DRM_DEBUG_KMS("Sink CRC couldn't be stopped properly\n");
-   ret = -EIO;
-   goto out;
-   }
+  buf & ~DP_TEST_SINK_START) < 0)
+   goto report_failure;
 
do {
intel_wait_for_vblank(dev_priv, intel_crtc->pipe);
+   if (drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_SINK_MISC, &buf)
+   < 0)
+   goto e_io;
 
-   if (drm_dp_dpcd_readb(&intel_dp->aux,
- DP_TEST_SINK_MISC, &buf) < 0) {
-   ret = -EIO;
-   goto out;
-   }
count = buf & DP_TEST_COUNT_MASK;
} while (--attempts && count);
 
@@ -3923,9 +3915,15 @@ static int intel_dp_sink_crc_stop(struct intel_dp 
*intel_dp)
ret = -ETIMEDOUT;
}
 
- out:
+enable_ips:
hsw_enable_ips(intel_crtc);
return ret;
+
+report_failure:
+   DRM_DEBUG_KMS("Sink CRC couldn't be stopped properly\n");
+e_io:
+   ret = -EIO;
+   goto enable_ips;
 }
 
 static int intel_dp_sink_crc_start(struct intel_dp *intel_dp)
-- 
2.14.3

___
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: Dump watermark info in i915_display_info. (rev2)

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

Series: drm/i915: Dump watermark info in i915_display_info. (rev2)
URL   : https://patchwork.freedesktop.org/series/32532/
State : failure

== Summary ==

Series 32532v2 drm/i915: Dump watermark info in i915_display_info.
https://patchwork.freedesktop.org/api/1.0/series/32532/revisions/2/mbox/

Test gem_exec_flush:
Subgroup basic-wb-rw-default:
pass   -> INCOMPLETE (fi-cnl-y)
Test pm_backlight:
Subgroup basic-brightness:
pass   -> INCOMPLETE (fi-skl-6700hq)

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:444s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:449s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:372s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:526s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:263s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:497s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:496s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:494s
fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
time:476s
fi-cfl-s total:289  pass:253  dwarn:4   dfail:0   fail:0   skip:32  
time:553s
fi-cnl-y total:73   pass:56   dwarn:0   dfail:0   fail:0   skip:16 
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:415s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:250s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:580s
fi-glk-dsi   total:289  pass:258  dwarn:0   dfail:0   fail:1   skip:30  
time:486s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:437s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:427s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:440s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:493s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:454s
fi-kbl-7500u total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  
time:497s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:571s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:477s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:582s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:545s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:456s
fi-skl-6700hqtotal:251  pass:226  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:521s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:496s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:454s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:561s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:422s

5c82a37eff83ab4e60e760fbaf03db5ba0563497 drm-tip: 2017y-10m-23d-18h-06m-28s UTC 
integration manifest
a6fc83ce39c5 drm/i915: Dump watermark info in i915_display_info, v2.

== Logs ==

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


[Intel-gfx] ✗ Fi.CI.BAT: warning for meson: makefile integration cleanup

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

Series: meson: makefile integration cleanup
URL   : https://patchwork.freedesktop.org/series/32519/
State : warning

== Summary ==

IGT patchset tested on top of latest successful build
e5f7fac9f120b0dcbf370c681b8872b8c29bf890 meson: intel_dp_compliance depends on 
libudev

with latest DRM-Tip kernel build CI_DRM_3276
5c82a37eff83 drm-tip: 2017y-10m-23d-18h-06m-28s UTC integration manifest

No testlist changes.

Test chamelium:
Subgroup dp-crc-fast:
pass   -> FAIL   (fi-kbl-7500u) fdo#102514
Test kms_frontbuffer_tracking:
Subgroup basic:
fail   -> PASS   (fi-glk-dsi)
Test drv_module_reload:
Subgroup basic-reload:
pass   -> DMESG-WARN (fi-bsw-n3050)

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:444s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:461s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:374s
fi-bsw-n3050 total:289  pass:242  dwarn:1   dfail:0   fail:0   skip:46  
time:531s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:264s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:499s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:497s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:494s
fi-cfl-s total:289  pass:253  dwarn:4   dfail:0   fail:0   skip:32  
time:561s
fi-cnl-y total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:602s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:419s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:251s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:579s
fi-glk-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:489s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:432s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:434s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:438s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:484s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:461s
fi-kbl-7500u total:289  pass:263  dwarn:1   dfail:0   fail:1   skip:24  
time:480s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:582s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:476s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:582s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:551s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:458s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:648s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:524s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:501s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:461s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:565s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:418s

== Logs ==

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


[Intel-gfx] [PATCH xf86-video-intel v3] hmm

2017-10-24 Thread Chris Wilson
---
 src/sna/gen6_common.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/sna/gen6_common.h b/src/sna/gen6_common.h
index b53ec0c9..05f76f83 100644
--- a/src/sna/gen6_common.h
+++ b/src/sna/gen6_common.h
@@ -87,7 +87,7 @@ static int prefer_blt_bo(struct sna *sna,
if (PREFER_RENDER)
return PREFER_RENDER < 0;
 
-   if (dst->rq)
+   if (__kgem_bo_is_busy(&sna->kgem, dst))
return RQ_IS_BLT(dst->rq);
 
if (sna->flags & SNA_POWERSAVE)
@@ -97,7 +97,7 @@ static int prefer_blt_bo(struct sna *sna,
if (sna->render_state.gt > 1)
return false;
 
-   if (src->rq)
+   if (__kgem_bo_is_busy(&sna->kgem, src))
return RQ_IS_BLT(src->rq);
 
if (src->tiling == I915_TILING_Y)
@@ -157,8 +157,8 @@ prefer_render_ring(struct sna *sna, struct kgem_bo *bo)
if (sna->kgem.ring != KGEM_NONE && NO_RING_SWITCH(sna))
 return false;
 
-   if (kgem_bo_is_render(bo))
-   return true;
+   if (__kgem_bo_is_busy(&sna->kgem, bo))
+   return !RQ_IS_BLT(bo);
 
if (sna->flags & SNA_POWERSAVE)
return false;
-- 
2.15.0.rc1

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


[Intel-gfx] [PATCH igt v3] igt/gem_ctx_isolation: Check isolation of registers between contexts

2017-10-24 Thread Chris Wilson
A new context assumes that all of its registers are in the default state
when it is created. What may happen is that a register written by one
context may leak into the second, causing mass confusion.

Signed-off-by: Chris Wilson 
---
 tests/Makefile.sources|   1 +
 tests/gem_ctx_isolation.c | 790 ++
 2 files changed, 791 insertions(+)
 create mode 100644 tests/gem_ctx_isolation.c

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index ac9f90bc..d18b7461 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -57,6 +57,7 @@ TESTS_progs = \
gem_ctx_basic \
gem_ctx_create \
gem_ctx_exec \
+   gem_ctx_isolation \
gem_ctx_param \
gem_ctx_switch \
gem_ctx_thrash \
diff --git a/tests/gem_ctx_isolation.c b/tests/gem_ctx_isolation.c
new file mode 100644
index ..3a0ee19a
--- /dev/null
+++ b/tests/gem_ctx_isolation.c
@@ -0,0 +1,790 @@
+/*
+ * 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 "igt.h"
+#include "igt_dummyload.h"
+
+#define MAX_REG 0x4
+#define NUM_REGS (MAX_REG / sizeof(uint32_t))
+
+#define PAGE_ALIGN(x) ALIGN(x, 4096)
+
+#define DIRTY 0x1
+#define UNSAFE 0x2
+
+enum {
+   RCS_MASK = 0x1,
+   BCS_MASK = 0x2,
+   VCS_MASK = 0x4,
+   VECS_MASK = 0x8,
+};
+
+#define ALL ~0u
+#define GEN_RANGE(x, y) ((ALL >> (32 - (y - x + 1))) << x)
+
+#define LAST_KNOWN_GEN 10
+
+static const struct named_register {
+   const char *name;
+   unsigned int gen_mask;
+   unsigned int engine_mask;
+   uint32_t offset;
+} safe_registers[] = {
+   { "NOPID", ALL, RCS_MASK, 0x2094 },
+   { "MI_PREDICATE_RESULT_2", ALL, RCS_MASK, 0x23bc },
+   { "INSTPM", ALL, RCS_MASK, 0x20c0 },
+   { "IA_VERTICES_COUNT (low)", ALL, RCS_MASK, 0x2310 },
+   { "IA_VERTICES_COUNT (high)", ALL, RCS_MASK, 0x2314 },
+   { "IA_PRIMITIVES_COUNT (low)", ALL, RCS_MASK, 0x2318 },
+   { "IA_PRIMITIVES_COUNT (high)", ALL, RCS_MASK, 0x231c },
+   { "VS_INVOCATION_COUNT (low)", ALL, RCS_MASK, 0x2320 },
+   { "VS_INVOCATION_COUNT (high)", ALL, RCS_MASK, 0x2324 },
+   { "HS_INVOCATION_COUNT (low)", ALL, RCS_MASK, 0x2300 },
+   { "HS_INVOCATION_COUNT (high)", ALL, RCS_MASK, 0x2304 },
+   { "DS_INVOCATION_COUNT (low)", ALL, RCS_MASK, 0x2308 },
+   { "DS_INVOCATION_COUNT (high)", ALL, RCS_MASK, 0x230c },
+   { "GS_INVOCATION_COUNT (low)", ALL, RCS_MASK, 0x2328 },
+   { "GS_INVOCATION_COUNT (high)", ALL, RCS_MASK, 0x232c },
+   { "GS_PRIMITIVES_COUNT (low)", ALL, RCS_MASK, 0x2330 },
+   { "GS_PRIMITIVES_COUNT (high)", ALL, RCS_MASK, 0x2334 },
+   { "CL_INVOCATION_COUNT (low)", ALL, RCS_MASK, 0x2338 },
+   { "CL_INVOCATION_COUNT (high)", ALL, RCS_MASK, 0x233c },
+   { "CL_PRIMITIVES_COUNT (low)", ALL, RCS_MASK, 0x2340 },
+   { "CL_PRIMITIVES_COUNT (high)", ALL, RCS_MASK, 0x2344 },
+   { "PS_INVOCATION_COUNT_0 (low)", ALL, RCS_MASK, 0x22c8 },
+   { "PS_INVOCATION_COUNT_0 (high)", ALL, RCS_MASK, 0x22cc },
+   { "PS_DEPTH_COUNT_0 (low)", ALL, RCS_MASK, 0x22d8 },
+   { "PS_DEPTH_COUNT_0 (high)", ALL, RCS_MASK, 0x22dc },
+   { "GPUGPU_DISPATCHDIMX", ALL, RCS_MASK, 0x2500 },
+   { "GPUGPU_DISPATCHDIMY", ALL, RCS_MASK, 0x2504 },
+   { "GPUGPU_DISPATCHDIMZ", ALL, RCS_MASK, 0x2508 },
+   { "MI_PREDICATE_SRC0 (low)", ALL, RCS_MASK, 0x2400 },
+   { "MI_PREDICATE_SRC0 (high)", ALL, RCS_MASK, 0x2404 },
+   { "MI_PREDICATE_SRC1 (low)", ALL, RCS_MASK, 0x2408 },
+   { "MI_PREDICATE_SRC1 (high)", ALL, RCS_MASK, 0x240c },
+   { "MI_PREDICATE_DATA (low)", ALL, RCS_MASK, 0x2410 },
+   { "MI_PREDICATE_DATA (high)", ALL, RCS_MASK, 0x2414 },
+   { "MI_PRED_RESULT", ALL, RCS_MASK, 0x2418 },
+   { "3DPRIM_END_OFFSET", ALL, RCS_MASK, 0x2420 },
+   { "3DPRIM_START_VERTEX"

Re: [Intel-gfx] [PATCH xf86-video-intel v3] hmm

2017-10-24 Thread Chris Wilson
I am really not paying attention to the directory hopping between
machines! Sorry.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915/huc: Use helper function while waiting for DMA completion

2017-10-24 Thread Michal Wajdeczko
On Tue, 24 Oct 2017 13:23:45 +0200, Chris Wilson  
 wrote:



Quoting Michal Wajdeczko (2017-10-24 11:50:56)

Waiting for DMA status register can be done with dedicated function.
Lets use it as additional bonus will be smaller driver footprint.

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_huc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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

index c8a48cb..98d1725 100644
--- a/drivers/gpu/drm/i915/intel_huc.c
+++ b/drivers/gpu/drm/i915/intel_huc.c
@@ -151,7 +151,7 @@ static int huc_ucode_xfer(struct intel_uc_fw  
*huc_fw, struct i915_vma *vma)
I915_WRITE(DMA_CTRL, _MASKED_BIT_ENABLE(HUC_UKERNEL |  
START_DMA));


/* Wait for DMA to finish */
-   ret = wait_for((I915_READ(DMA_CTRL) & START_DMA) == 0, 100);
+   ret = intel_wait_for_register_fw(dev_priv, DMA_CTRL, START_DMA,  
0, 100);


DRM_DEBUG_DRIVER("HuC DMA transfer wait over with ret %d\n",  
ret);


Reviewed-by: Chris Wilson 

Aside, what's the serialisation so that we only try to load one fw at a
time?


It looks that we just wait right after starting DMA. And if we attempt to
next DMA while previous is still running then it will be likely silently
ignored by HW as control bit START_DMA would be still on.

If we want to be bullet-proof then maybe before we start programming new
DMA xfer we should verify that DMA hw is idle (and then wait little more
or just abort immediately)

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


Re: [Intel-gfx] drm/i915/gvt: Use common error handling code in shadow_workload_ring_buffer()

2017-10-24 Thread Dan Carpenter
The point of unwind code is to undo what was done earlier.  If a
function allocates a list of things, using standard unwind style makes
it simpler, safer and more readable.

This isn't the case here.  Instead of making the code more readable,
we're making it more convoluted.  It's just that two out of three error
messages happened to be the same and Markus wants to save a bit of
memory by using the same string.  The memory savings is not so big that
it's worth making the code less readable.

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


Re: [Intel-gfx] [PATCH 2/4] drm/i915: Synchronize irq before parking each engine

2017-10-24 Thread Mika Kuoppala
Chris Wilson  writes:

> Quoting Chris Wilson (2017-10-23 22:32:35)
>> When we park the engine (upon idling), we kill the irq tasklet. However,
>> to be sure that it is not restarted by a final interrupt after doing so,
>> flush the interrupt handler before parking. As we only park the engines
>> when we believe the system is idle, there should not be any spurious
>> interrupts later to distrub us; so flushing the final in-flight
>> interrupt should be sufficient.
>> 
>> Signed-off-by: Chris Wilson 
>> Cc: Joonas Lahtinen 
>> Cc: Mika Kuoppala 
>> Cc: Imre Deak 
>> ---
>>  drivers/gpu/drm/i915/i915_gem.c | 6 ++
>>  1 file changed, 6 insertions(+)
>> 
>> diff --git a/drivers/gpu/drm/i915/i915_gem.c 
>> b/drivers/gpu/drm/i915/i915_gem.c
>> index bb0e85043e01..b547a6327d34 100644
>> --- a/drivers/gpu/drm/i915/i915_gem.c
>> +++ b/drivers/gpu/drm/i915/i915_gem.c
>> @@ -3327,6 +3327,12 @@ i915_gem_idle_work_handler(struct work_struct *work)
>> if (new_requests_since_last_retire(dev_priv))
>> goto out_unlock;
>>  
>> +   /*
>> +* Be paranoid and flush a concurrent interrupt to make sure
>> +* we don't reactivate any irq tasklets after parking.
>
> * FIXME: Note that even though we have waited for execlists to be idle,
> * there may still be an in-flight interrupt even though the CSB
> * is now empty. synchronize_irq() makes sure that the residual
> * interrupt is completed before we continue, but it doesn't prevent
> * the HW from raising that residual interrupt later. To complete
> * the shield we should coordinate disabling the CS irq with
> * flushing the residual interrupt.

I would call it spurious instead of residual as there is no real
reason for it.

Reviewed-by: Mika Kuoppala 

>
>> +*/
>> +   synchronize_irq(dev_priv->drm.irq);
>> +
>> /*
>>  * We are committed now to parking the engines, make sure there
>>  * will be no more interrupts arriving later.
>> -- 
>> 2.15.0.rc1
>> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/execlists: Remove the priority "optimisation"

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

Series: drm/i915/execlists: Remove the priority "optimisation"
URL   : https://patchwork.freedesktop.org/series/32533/
State : success

== Summary ==

Test perf:
Subgroup polling:
fail   -> PASS   (shard-hsw) fdo#102252
Test kms_busy:
Subgroup extended-modeset-hang-oldfb-with-reset-render-A:
dmesg-warn -> PASS   (shard-hsw) fdo#102249 +1
Test drv_module_reload:
Subgroup basic-reload-inject:
dmesg-warn -> PASS   (shard-hsw) fdo#102707
Test kms_setmode:
Subgroup basic:
pass   -> FAIL   (shard-hsw) fdo#99912

fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
fdo#102249 https://bugs.freedesktop.org/show_bug.cgi?id=102249
fdo#102707 https://bugs.freedesktop.org/show_bug.cgi?id=102707
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912

shard-hswtotal:2540 pass:1432 dwarn:2   dfail:0   fail:9   skip:1097 
time:9163s

== Logs ==

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


[Intel-gfx] ✓ Fi.CI.BAT: success for igt/lib: Ignoring subtest name case

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

Series: igt/lib: Ignoring subtest name case
URL   : https://patchwork.freedesktop.org/series/32529/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
e5f7fac9f120b0dcbf370c681b8872b8c29bf890 meson: intel_dp_compliance depends on 
libudev

with latest DRM-Tip kernel build CI_DRM_3276
5c82a37eff83 drm-tip: 2017y-10m-23d-18h-06m-28s UTC integration manifest

No testlist changes.

Test chamelium:
Subgroup dp-crc-fast:
pass   -> FAIL   (fi-kbl-7500u) fdo#102514

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:445s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:461s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:373s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:529s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:266s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:500s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:501s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:495s
fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
time:476s
fi-cfl-s total:289  pass:253  dwarn:4   dfail:0   fail:0   skip:32  
time:560s
fi-cnl-y total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:595s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:416s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:252s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:580s
fi-glk-dsi   total:289  pass:258  dwarn:0   dfail:0   fail:1   skip:30  
time:490s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:430s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:430s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:431s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:484s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:459s
fi-kbl-7500u total:289  pass:263  dwarn:1   dfail:0   fail:1   skip:24  
time:483s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:577s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:476s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:584s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:547s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:467s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:644s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:522s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:496s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:459s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:569s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:423s

== Logs ==

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


Re: [Intel-gfx] [PATCH 3/4] drm/i915: Filter out spurious execlists context-switch interrupts

2017-10-24 Thread Mika Kuoppala
Chris Wilson  writes:

> Back in commit a4b2b01523a8 ("drm/i915: Don't mark an execlists
> context-switch when idle") we noticed the presence of late
> context-switch interrupts. We were able to filter those out by looking
> at whether the ELSP remained active, but in commit beecec901790
> ("drm/i915/execlists: Preemption!") that became problematic as we now
> anticipate receiving a context-switch event for preemption while ELSP
> may be empty. To restore the spurious interrupt suppression, add a
> counter for the expected number of pending context-switches and skip if
> we do not need to handle this interrupt to make forward progress.
>
> v2: Don't forget to switch on for preempt.
> v3: Reduce the counter to a on/off boolean tracker. Declare the HW as
> active when we first submit, and idle after the final completion event
> (with which we confirm the HW says it is idle), and track each source
> of activity separately. With a finite number of sources, it should us
> debug which gets stuck.
>
> Fixes: beecec901790 ("drm/i915/execlists: Preemption!")
> Signed-off-by: Chris Wilson 
> Cc: Michal Winiarski 
> Cc: Tvrtko Ursulin 
> Cc: Arkadiusz Hiler 
> Cc: Mika Kuoppala 
> Cc: Joonas Lahtinen 
> ---
>  drivers/gpu/drm/i915/i915_guc_submission.c |  3 +++
>  drivers/gpu/drm/i915/i915_irq.c|  6 --
>  drivers/gpu/drm/i915/intel_engine_cs.c |  5 +++--
>  drivers/gpu/drm/i915/intel_lrc.c   | 27 ++--
>  drivers/gpu/drm/i915/intel_ringbuffer.h| 34 
> --
>  5 files changed, 62 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
> b/drivers/gpu/drm/i915/i915_guc_submission.c
> index a2e8114b739d..f84c267728fd 100644
> --- a/drivers/gpu/drm/i915/i915_guc_submission.c
> +++ b/drivers/gpu/drm/i915/i915_guc_submission.c
> @@ -610,6 +610,7 @@ static void i915_guc_dequeue(struct intel_engine_cs 
> *engine)
>   execlists->first = rb;
>   if (submit) {
>   port_assign(port, last);
> + execlists_set_active(execlists, EXECLISTS_ACTIVE_USER);
>   i915_guc_submit(engine);
>   }
>   spin_unlock_irq(&engine->timeline->lock);
> @@ -633,6 +634,8 @@ static void i915_guc_irq_handler(unsigned long data)
>  
>   rq = port_request(&port[0]);
>   }
> + if (!rq)
> + execlists_clear_active(execlists, EXECLISTS_ACTIVE_USER);
>  
>   if (!port_isset(last_port))
>   i915_guc_dequeue(engine);
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index b1296a55c1e4..f8205841868b 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1388,8 +1388,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 (READ_ONCE(engine->execlists.active)) {
> + __set_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
> + tasklet = true;

These two in here feel naturally attracted to eachothers. Perhaps
a future patch will meld them together.

Reviewed-by: Mika Kuoppala 

> + }
>   }
>  
>   if (iir & (GT_RENDER_USER_INTERRUPT << test_shift)) {
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index a47a9c6bea52..ab5bf4e2e28e 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -1548,8 +1548,8 @@ bool intel_engine_is_idle(struct intel_engine_cs 
> *engine)
>   if (test_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted))
>   return false;
>  
> - /* Both ports drained, no more ELSP submission? */
> - if (port_request(&engine->execlists.port[0]))
> + /* Waiting to drain ELSP? */
> + if (READ_ONCE(engine->execlists.active))
>   return false;
>  
>   /* ELSP is empty, but there are ready requests? */
> @@ -1749,6 +1749,7 @@ void intel_engine_dump(struct intel_engine_cs *engine, 
> struct drm_printer *m)
>  idx);
>   }
>   }
> + drm_printf(m, "\t\tHW active? 0x%x\n", execlists->active);
>   rcu_read_unlock();
>   } else if (INTEL_GEN(dev_priv) > 6) {
>   drm_printf(m, "\tPP_DIR_BASE: 0x%08x\n",
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 7f45dd7dc3e5..233c992a886b 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -575,7 +575,8 @@ static void execlists_dequeue(struct intel_engine_cs 
> *engine)
>* the state of the GPU is known (idle).
>*/
>   inject_preempt_context(engine);
> -  

Re: [Intel-gfx] drm/i915/gvt: Use common error handling code in shadow_workload_ring_buffer()

2017-10-24 Thread SF Markus Elfring
> This isn't the case here.

I find your view interesting for further clarification somehow.


> Instead of making the code more readable, we're making it more convoluted.

Can the shown software refactoring usually help here?


> It's just that two out of three error messages happened to be the same

This is true.


> and Markus wants to save a bit of memory by using the same string.

And also the same executable code (besides an identical error message).


> The memory savings is not so big that it's worth making the code less 
> readable.

How does such a feedback fit to information for the deletion of questionable
messages at other source code places?

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


Re: [Intel-gfx] drm/i915/gvt: Use common error handling code in shadow_workload_ring_buffer()

2017-10-24 Thread Joe Perches
On Tue, 2017-10-24 at 17:26 +0300, Dan Carpenter wrote:
> The point of unwind code is to undo what was done earlier.  If a
> function allocates a list of things, using standard unwind style makes
> it simpler, safer and more readable.
> 
> This isn't the case here.  Instead of making the code more readable,
> we're making it more convoluted.  It's just that two out of three error
> messages happened to be the same and Markus wants to save a bit of
> memory by using the same string.  The memory savings is not so big that
> it's worth making the code less readable.

I agree with Dan.

It doesn't save any real memory either as the compiler/linker
reuses the repeated string.

It might, depending on the compiler, save a few bytes of
object code as the compiler may not optimize the repeated
call away though.  But a good compiler could do that too.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 4/4] warn

2017-10-24 Thread Mika Kuoppala
Chris Wilson  writes:

> ---
>  drivers/gpu/drm/i915/i915_irq.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index f8205841868b..e4bd20ce031d 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1391,6 +1391,9 @@ gen8_cs_irq_handler(struct intel_engine_cs *engine, u32 
> iir, int test_shift)
>   if (READ_ONCE(engine->execlists.active)) {
>   __set_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
>   tasklet = true;
> + } else if (WARN_ON(!engine->i915->gt.awake)) {

READ_ONCE

I'll get my coat.
-Mika

> + struct drm_printer p = 
> drm_info_printer(engine->i915->drm.dev);
> + intel_engine_dump(engine, &p);
>   }
>   }
>  
> -- 
> 2.15.0.rc1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] drm/i915/gvt: Use common error handling code in shadow_workload_ring_buffer()

2017-10-24 Thread SF Markus Elfring
>> …  It's just that two out of three error
>> messages happened to be the same and Markus wants to save a bit of
>> memory by using the same string.  The memory savings is not so big that
>> it's worth making the code less readable.
> 
> I agree with Dan.
> 
> It doesn't save any real memory either as the compiler/linker
> reuses the repeated string.

It might depend on passing appropriate parameters.


> It might, depending on the compiler, save a few bytes of
> object code as the compiler may not optimize the repeated
> call away though.

I am trying to show corresponding change possibilities.


> But a good compiler could do that too.

Do you prefer to delegate the proposed software refactoring
only to a corresponding optimiser?

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


[Intel-gfx] ✓ Fi.CI.BAT: success for igt/kms_rotation_crc: Add horizontal flip subtest. (rev2)

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

Series: igt/kms_rotation_crc: Add horizontal flip subtest. (rev2)
URL   : https://patchwork.freedesktop.org/series/31407/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
e5f7fac9f120b0dcbf370c681b8872b8c29bf890 meson: intel_dp_compliance depends on 
libudev

with latest DRM-Tip kernel build CI_DRM_3276
5c82a37eff83 drm-tip: 2017y-10m-23d-18h-06m-28s UTC integration manifest

Testlist changes:
+igt@kms_rotation_crc@primary-x-tiled-reflect-x-0
+igt@kms_rotation_crc@primary-x-tiled-reflect-x-0-flip
+igt@kms_rotation_crc@primary-x-tiled-reflect-x-180
+igt@kms_rotation_crc@primary-x-tiled-reflect-x-180-flip
+igt@kms_rotation_crc@primary-yf-tiled-reflect-x-0
+igt@kms_rotation_crc@primary-yf-tiled-reflect-x-0-flip
+igt@kms_rotation_crc@primary-yf-tiled-reflect-x-90
+igt@kms_rotation_crc@primary-yf-tiled-reflect-x-90-flip
+igt@kms_rotation_crc@primary-yf-tiled-reflect-x-180
+igt@kms_rotation_crc@primary-yf-tiled-reflect-x-180-flip
+igt@kms_rotation_crc@primary-yf-tiled-reflect-x-270
+igt@kms_rotation_crc@primary-yf-tiled-reflect-x-270-flip
+igt@kms_rotation_crc@primary-y-tiled-reflect-x-0
+igt@kms_rotation_crc@primary-y-tiled-reflect-x-0-flip
+igt@kms_rotation_crc@primary-y-tiled-reflect-x-90
+igt@kms_rotation_crc@primary-y-tiled-reflect-x-90-flip
+igt@kms_rotation_crc@primary-y-tiled-reflect-x-180
+igt@kms_rotation_crc@primary-y-tiled-reflect-x-180-flip
+igt@kms_rotation_crc@primary-y-tiled-reflect-x-270
+igt@kms_rotation_crc@primary-y-tiled-reflect-x-270-flip

Test chamelium:
Subgroup dp-crc-fast:
pass   -> FAIL   (fi-kbl-7500u) fdo#102514

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:442s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:452s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:376s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:527s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:264s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:501s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:496s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:499s
fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
time:488s
fi-cfl-s total:289  pass:253  dwarn:4   dfail:0   fail:0   skip:32  
time:561s
fi-cnl-y total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:632s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:422s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:247s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:591s
fi-glk-dsi   total:289  pass:258  dwarn:0   dfail:0   fail:1   skip:30  
time:483s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:427s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:430s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:437s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:484s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:464s
fi-kbl-7500u total:289  pass:263  dwarn:1   dfail:0   fail:1   skip:24  
time:480s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:571s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:476s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:583s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:548s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:455s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:648s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:523s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:505s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:462s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:565s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:418s

== Logs ==

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


[Intel-gfx] ✗ Fi.CI.BAT: failure for tests/kms_atomic_transition: Make tests pass

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

Series: tests/kms_atomic_transition: Make tests pass
URL   : https://patchwork.freedesktop.org/series/32361/
State : failure

== Summary ==

Series 32361 revision 1 was fully merged or fully failed: no git log

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_395/
___
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 [1/2] meson: don't assume xmlrpc-c-config is there

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

Series: series starting with [1/2] meson: don't assume xmlrpc-c-config is there
URL   : https://patchwork.freedesktop.org/series/32511/
State : failure

== Summary ==

Series 32511 revision 1 was fully merged or fully failed: no git log

== Logs ==

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


Re: [Intel-gfx] drm/i915/gvt: Use common error handling code in shadow_workload_ring_buffer()

2017-10-24 Thread Joe Perches
On Tue, 2017-10-24 at 16:51 +0200, SF Markus Elfring wrote:
> Do you prefer to delegate the proposed software refactoring
> only to a corresponding optimiser?

yes.
___
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 [1/2] meson: don't assume xmlrpc-c-config is there

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

Series: series starting with [1/2] meson: don't assume xmlrpc-c-config is there
URL   : https://patchwork.freedesktop.org/series/32511/
State : failure

== Summary ==

Series 32511 revision 1 was fully merged or fully failed: no git log

== Logs ==

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


[Intel-gfx] ✗ Fi.CI.BAT: failure for igt/gem_ctx_isolation: Check isolation of registers between contexts (rev3)

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

Series: igt/gem_ctx_isolation: Check isolation of registers between contexts 
(rev3)
URL   : https://patchwork.freedesktop.org/series/32531/
State : failure

== Summary ==

IGT patchset build failed on latest successful build
e5f7fac9f120b0dcbf370c681b8872b8c29bf890 meson: intel_dp_compliance depends on 
libudev

The Meson build system
Version: 0.40.1
Source dir: /home/cidrm/intel-gpu-tools
Build dir: /home/cidrm/intel-gpu-tools/build
Build type: native build
Project name: IGT gpu tests
Native c compiler: ccache cc (gcc 6.3.0)
Build machine cpu family: x86_64
Build machine cpu: x86_64
Compiler for c supports argument -Wno-unused-parameter: YES
Compiler for c supports argument -Wno-sign-compare: YES
Compiler for c supports argument -Wno-missing-field-initializers: YES
Compiler for c supports argument -Wno-clobbered: YES
Compiler for c supports argument -Wno-type-limits: YES
Compiler for c supports argument -Wimplicit-fallthrough=0: NO
Found pkg-config: /usr/bin/pkg-config (0.29.1)
Native dependency libdrm found: YES 2.4.85
Native dependency libdrm_intel found: YES 2.4.85
Dependency libdrm_vc4 found: NO
Dependency libdrm_nouveau found: NO
Dependency libdrm_amdgpu found: NO
Native dependency pciaccess found: YES 0.13.4
Native dependency libkmod found: YES 22
Native dependency libprocps found: YES 3.3.12
Native dependency cairo found: YES 1.14.8
Native dependency libudev found: YES 232
Native dependency glib-2.0 found: YES 2.52.0
Native dependency libunwind found: YES 1.1
Native dependency gsl found: YES 2.3
Dependency alsa found: NO
Native dependency pixman-1 found: YES 0.34.0
Dependency xmlrpc found: NO
Dependency xmlrpc_util found: NO
Dependency xmlrpc_client found: NO
Program xmlrpc-c-config found: YES (/usr/bin/xmlrpc-c-config)
Dependency threads found: YES
Library m found: YES
Library rt found: YES
Library dl found: YES
Library z found: YES
Has header "linux/kd.h": YES
Has header "sys/kd.h": YES
Has header "libgen.h": YES
Has header "sys/io.h": YES
Has header "cpuid.h": YES
Checking whether type "struct sysinfo" has member "totalram": YES
Configuring config.h using configuration
Program generate_testlist.sh found: YES 
(/home/cidrm/intel-gpu-tools/tests/generate_testlist.sh)
Program igt_command_line.sh found: YES 
(/home/cidrm/intel-gpu-tools/tests/igt_command_line.sh)
Configuring intel_aubdump using configuration
Program flex found: YES (/usr/bin/flex)
Program bison found: YES (/usr/bin/bison)
Configuring intel-gen4asm.pc using configuration
Program test/run-test.sh found: YES (/bin/sh 
/home/cidrm/intel-gpu-tools/assembler/test/run-test.sh)
Native dependency xv found: YES 1.0.11
Native dependency x11 found: YES 1.6.4
Native dependency xext found: YES 1.3.3
Native dependency dri2proto found: YES 2.8
Native dependency cairo-xlib found: YES 1.14.8
Dependency xrandr found: NO
Configuring defs.rst using configuration
Program rst2man found: YES (/usr/bin/rst2man)
Program rst2man.sh found: YES (/home/cidrm/intel-gpu-tools/man/rst2man.sh)
Build targets in project: 369
ninja: Entering directory `build'
[1/743] Compiling c object 
'lib/tests/igt_simple_test_subtests@exe/igt_simple_test_subtests.c.o'
[2/743] Compiling c object 'tests/core_auth@exe/core_auth.c.o'
[3/743] Compiling c object 'lib/igt@sha/dummy.c.o'
[4/743] Compiling c object 'lib/tests/igt_simulation@exe/igt_simulation.c.o'
[5/743] Compiling c object 'lib/tests/igt_list_only@exe/igt_list_only.c.o'
[6/743] Compiling c object 'lib/tests/igt_fork_helper@exe/igt_fork_helper.c.o'
[7/743] Compiling c object 'lib/tests/igt_hdmi_inject@exe/igt_hdmi_inject.c.o'
[8/743] Compiling c object 'lib/tests/igt_exit_handler@exe/igt_exit_handler.c.o'
[9/743] Compiling c object 'lib/tests/igt_stats@exe/igt_stats.c.o'
[10/743] Compiling c object 'lib/tests/igt_segfault@exe/igt_segfault.c.o'
[11/743] Compiling c object 
'lib/tests/igt_subtest_group@exe/igt_subtest_group.c.o'
[12/743] Compiling c object 'lib/tests/igt_assert@exe/igt_assert.c.o'
[13/743] Compiling c object 'lib/tests/igt_can_fail@exe/igt_can_fail.c.o'
[14/743] Compiling c object 
'lib/tests/igt_can_fail_simple@exe/igt_can_fail_simple.c.o'
[15/743] Compiling c object 'lib/tests/igt_no_exit@exe/igt_no_exit.c.o'
[16/743] Compiling c object 
'lib/tests/igt_no_exit_list_only@exe/igt_no_exit_list_only.c.o'
[17/743] Compiling c object 'lib/tests/igt_no_subtest@exe/igt_no_subtest.c.o'
[18/743] Compiling c object 
'lib/tests/igt_invalid_subtest_name@exe/igt_invalid_subtest_name.c.o'
[19/743] Compiling c object 'lib/tests/igt_timeout@exe/igt_timeout.c.o'
[20/743] Compiling c object 
'tests/core_get_client_auth@exe/core_get_client_auth.c.o'
[21/743] Compiling c object 
'tests/gem_fenced_exec_thrash@exe/gem_fenced_exec_thrash.c.o'
[22/743] Compiling c object 'tests/core_getclient@exe/core_getclient.c.o'
[23/743] Compiling c object 'tests/core_getversion@exe/core_getversion.c.o'
[24/743] Compiling c object 'tests/core_getstats@exe/core_getstats.c.o'
[25/743] Compiling c object 
'tests/core_setmast

Re: [Intel-gfx] drm/i915/gvt: Use common error handling code in shadow_workload_ring_buffer()

2017-10-24 Thread SF Markus Elfring
>> Do you prefer to delegate the proposed software refactoring
>> only to a corresponding optimiser?
> 
> yes.

Will any applications around the semantic patch language
(Coccinelle software) fit also in the preferred tool category?

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


Re: [Intel-gfx] [PATCH 4/4] warn

2017-10-24 Thread Chris Wilson
Quoting Mika Kuoppala (2017-10-24 15:46:27)
> Chris Wilson  writes:
> 
> > ---
> >  drivers/gpu/drm/i915/i915_irq.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c 
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index f8205841868b..e4bd20ce031d 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -1391,6 +1391,9 @@ gen8_cs_irq_handler(struct intel_engine_cs *engine, 
> > u32 iir, int test_shift)
> >   if (READ_ONCE(engine->execlists.active)) {
> >   __set_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
> >   tasklet = true;
> > + } else if (WARN_ON(!engine->i915->gt.awake)) {
> 
> READ_ONCE

Sure. Too bad this patch is just a figment of your imagination.

Pushed the rest, hopefully ending the plague of random deaths.
Thanks for the review,
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915/execlists: Remove the priority "optimisation"

2017-10-24 Thread Chris Wilson
Quoting Michał Winiarski (2017-10-24 13:26:59)
> On Tue, Oct 24, 2017 at 12:55:01PM +0100, Chris Wilson wrote:
> > Originally we set the priority to max upon inserting the request into
> > the execlists queue (and removing it from the scheduler lists). We could
> > then use the prio==INT_MAX as a shortcut within execlists_schedule() to
> > detect the end of the dependency chain. Since commit 1f181225f8ec
> > ("drm/i915/execlists: Keep request->priority for its lifetime") this is
> > no longer true as we use the request completion as an indicator the
> > schedule dependency chain is complete instead. (This allows us to then
> > reschedule requests even when its context is in flight.) However, this
> > makes the GEM_BUG_ON() inside execlists_schedule() racy as we may change
> > the rq->prio at the same time. As the assertion is useful, let's keep
> > the assertion and remove the micro-optimisation.
> > 
> > Fixes: 1f181225f8ec ("drm/i915/execlists: Keep request->priority for its 
> > lifetime")
> > Signed-off-by: Chris Wilson 
> > Cc: Michał Winiarski 
> > Cc: Joonas Lahtinen 
> 
> Reviewed-by: Michał Winiarski 

And pushed, thanks for the poke.
-Chris
___
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/kms_atomic_transition: Make tests pass

2017-10-24 Thread Maarten Lankhorst
Op 24-10-17 om 14:10 schreef Petri Latvala:
> On Mon, Oct 23, 2017 at 12:15:34PM +0200, Maarten Lankhorst wrote:
>> Op 23-10-17 om 11:35 schreef Petri Latvala:
>>>
>>> On Fri, Oct 20, 2017 at 03:24:15PM +0200, Maarten Lankhorst wrote:
>>>
>>> Subject: [Intel-gfx] [PATCH i-g-t] tests/kms_atomic_transition: Make tests 
>>> pass
>>>
>>>
>>> You have an excellent explanation of what this patch does in the long
>>> description, and yet this short description says nothing of value.
>>>
>>>
>>>
>> Is this patch good with subject: 'tests/kms_atomic_transition: Do not update 
>> unbound planes'?
>>
> LGTM.
>
> Explain the change of making fd_completed() call conditional too in
> the commit message and
>
> Reviewed-by: Petri Latvala 

Thanks, pushed. :)

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


Re: [Intel-gfx] [PATCH i-g-t] lib/igt_kms: Only print changed mode objects during atomic commit.

2017-10-24 Thread Maarten Lankhorst
Op 24-10-17 om 14:34 schreef Petri Latvala:
> On Fri, Oct 20, 2017 at 03:23:57PM +0200, Maarten Lankhorst wrote:
>> When we only print mode objects that have changed properties, we
>> reduce a lot of the spam. Fortuantely we have a single bitfield
>> now that gets printed when something is changed. Use that to decrease
>> the amount of spam.
>
> s/Fortuantely/Fortunately/
Fixed, thanks for catching it!
>
>> Signed-off-by: Maarten Lankhorst 
> Reviewed-by: Petri Latvala 

Thanks, pushed. :)

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


[Intel-gfx] [PATCH] drm/i915/selftests: Convert timers to use timer_setup()

2017-10-24 Thread Kees Cook
In preparation for unconditionally passing the struct timer_list pointer to
all timer callbacks, switch to using the new timer_setup() and from_timer()
to pass the timer pointer explicitly.

Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: David Airlie 
Cc: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Kees Cook 
---
 drivers/gpu/drm/i915/selftests/lib_sw_fence.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/selftests/lib_sw_fence.c 
b/drivers/gpu/drm/i915/selftests/lib_sw_fence.c
index 3790fdf44a1a..b26f07b55d86 100644
--- a/drivers/gpu/drm/i915/selftests/lib_sw_fence.c
+++ b/drivers/gpu/drm/i915/selftests/lib_sw_fence.c
@@ -49,9 +49,9 @@ void onstack_fence_fini(struct i915_sw_fence *fence)
i915_sw_fence_fini(fence);
 }
 
-static void timed_fence_wake(unsigned long data)
+static void timed_fence_wake(struct timer_list *t)
 {
-   struct timed_fence *tf = (struct timed_fence *)data;
+   struct timed_fence *tf = from_timer(tf, t, timer);
 
i915_sw_fence_commit(&tf->fence);
 }
@@ -60,7 +60,7 @@ void timed_fence_init(struct timed_fence *tf, unsigned long 
expires)
 {
onstack_fence_init(&tf->fence);
 
-   setup_timer_on_stack(&tf->timer, timed_fence_wake, (unsigned long)tf);
+   timer_setup_on_stack(&tf->timer, timed_fence_wake, 0);
 
if (time_after(expires, jiffies))
mod_timer(&tf->timer, expires);
-- 
2.7.4


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


[Intel-gfx] ✗ Fi.CI.IGT: warning for igt/lib: Ignoring subtest name case

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

Series: igt/lib: Ignoring subtest name case
URL   : https://patchwork.freedesktop.org/series/32529/
State : warning

== Summary ==

Test drv_module_reload:
Subgroup basic-reload-inject:
dmesg-warn -> PASS   (shard-hsw) fdo#102707
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-offscren-pri-shrfb-draw-render:
pass   -> SKIP   (shard-hsw)
Subgroup fbc-1p-primscrn-pri-shrfb-draw-render:
pass   -> SKIP   (shard-hsw)
Test perf:
Subgroup polling:
fail   -> PASS   (shard-hsw) fdo#102252
Test kms_busy:
Subgroup extended-modeset-hang-newfb-with-reset-render-B:
pass   -> DMESG-WARN (shard-hsw) fdo#103038
Subgroup extended-modeset-hang-oldfb-with-reset-render-B:
dmesg-warn -> PASS   (shard-hsw) fdo#102249 +1

fdo#102707 https://bugs.freedesktop.org/show_bug.cgi?id=102707
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
fdo#103038 https://bugs.freedesktop.org/show_bug.cgi?id=103038
fdo#102249 https://bugs.freedesktop.org/show_bug.cgi?id=102249

shard-hswtotal:2540 pass:1432 dwarn:1   dfail:0   fail:8   skip:1099 
time:9238s

== Logs ==

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


[Intel-gfx] [PATCH igt 1/2] lib/i915: Add a query for when the guc is enabled.

2017-10-24 Thread Chris Wilson
Signed-off-by: Chris Wilson 
Cc: Michał Winiarski 
---
 lib/i915/gem_submission.c | 12 
 lib/i915/gem_submission.h |  1 +
 2 files changed, 13 insertions(+)

diff --git a/lib/i915/gem_submission.c b/lib/i915/gem_submission.c
index efc3151f..2a57e7ab 100644
--- a/lib/i915/gem_submission.c
+++ b/lib/i915/gem_submission.c
@@ -126,3 +126,15 @@ bool gem_has_execlists(int fd)
 {
return gem_submission_method(fd) & GEM_SUBMISSION_EXECLISTS;
 }
+
+/**
+ * gem_has_guc_submission:
+ * @fd: open i915 drm file descriptor
+ *
+ * Feature test macro to query whether the driver is using the GuC as a
+ * hardware submission method.
+ */
+bool gem_has_guc_submission(int fd)
+{
+   return gem_submission_method(fd) & GEM_SUBMISSION_GUC;
+}
diff --git a/lib/i915/gem_submission.h b/lib/i915/gem_submission.h
index 783ed7a0..4f588aec 100644
--- a/lib/i915/gem_submission.h
+++ b/lib/i915/gem_submission.h
@@ -31,5 +31,6 @@ unsigned gem_submission_method(int fd);
 void gem_submission_print_method(int fd);
 bool gem_has_semaphores(int fd);
 bool gem_has_execlists(int fd);
+bool gem_has_guc_submission(int fd);
 
 #endif /* GEM_SUBMISSION_H */
-- 
2.15.0.rc1

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


  1   2   >