Re: [Intel-gfx] [PATCH 4/4] drm/i915: Enable atomic on VLV/CHV

2017-03-05 Thread Maarten Lankhorst
Op 03-03-17 om 16:19 schreef ville.syrj...@linux.intel.com:
> From: Ville Syrjälä 
>
> VLV/CHV watermarks are now able to handle the radiation, so
> mark these platforms as ready for atomic.
>
> Cc: Maarten Lankhorst 
> Suggested-by: Maarten Lankhorst 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index b1e9027a4f80..c8944bf65a36 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1214,9 +1214,8 @@ int i915_driver_load(struct pci_dev *pdev, const struct 
> pci_device_id *ent)
>   struct drm_i915_private *dev_priv;
>   int ret;
>  
> - /* Enable nuclear pageflip on ILK+, except vlv/chv */
> - if (!i915.nuclear_pageflip &&
> - (match_info->gen < 5 || match_info->has_gmch_display))
> + /* Enable nuclear pageflip on ILK+ */
> + if (!i915.nuclear_pageflip && match_info->gen < 5)
>   driver.driver_features &= ~DRIVER_ATOMIC;
>  
>   ret = -ENOMEM;

Reviewed-by: Maarten Lankhorst 

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


[Intel-gfx] [PATCH] drm/i915/gvt: add enable_execlists check before enable gvt

2017-03-05 Thread Chuanxiao Dong
The GVT-g needs execlists to be enabled otherwise gvt should be
disabled. Add a check for enable_execlists before enabling gvt.

Signed-off-by: Chuanxiao Dong 
---
 drivers/gpu/drm/i915/intel_gvt.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_gvt.c b/drivers/gpu/drm/i915/intel_gvt.c
index d23c0fc..3799cb3 100644
--- a/drivers/gpu/drm/i915/intel_gvt.c
+++ b/drivers/gpu/drm/i915/intel_gvt.c
@@ -77,6 +77,11 @@ int intel_gvt_init(struct drm_i915_private *dev_priv)
goto bail;
}
 
+   if (!i915.enable_execlists) {
+   DRM_DEBUG_DRIVER("Execlists unsupported, GVT-g is disabled\n");
+   goto bail;
+   }
+
/*
 * We're not in host or fail to find a MPT module, disable GVT-g
 */
-- 
2.7.4

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


Re: [Intel-gfx] [PATCH] drm/i915: suppress atomic commit error message under gvt-g env

2017-03-05 Thread bing.niu

Hi ville:
thanks for the reply. :)
yeah! we present a virtual monitor to guest associating with those 
vregs. however, we use remote display protocol like x11vnc to display 
vm's desktop.


cheer~

-Original Message-
From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] Sent: Friday, 
March 03, 2017 7:53 PM

To: Niu, Bing 
Cc: intel-gfx@lists.freedesktop.org; Lv, Zhiyuan 
Subject: Re: [Intel-gfx] [PATCH] drm/i915: suppress atomic commit error 
message under gvt-g env


On Fri, Mar 03, 2017 at 06:53:08AM -0500, bing@intel.com wrote:

From: Bing Niu 

under virtualization enviroment, it is possible guest update pipe
registers across vblank intervals due to overhead of mmio traps or vm
schedule out. However, it is safe since those pipe update happen in
virual registers and will not be committed to hardware.


Hmm. How are these virtual registers used? Do you present some kind of 
virtualized display for the guest? And if this stuff fails does that 
mean that guest will fail in doing atomic display updates?



suppress that
atomic commit error message under virtualization case to avoid
confusing user.

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

diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index b16a295..5ce1ec6 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -158,6 +158,7 @@ void intel_pipe_update_end(struct intel_crtc *crtc, struct 
intel_flip_work *work
int scanline_end = intel_get_crtc_scanline(crtc);
u32 end_vbl_count = intel_crtc_get_vblank_counter(crtc);
ktime_t end_vbl_time = ktime_get();
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);

if (work) {
work->flip_queued_vblank = end_vbl_count; @@ -184,7 +185,7 @@ 
void
intel_pipe_update_end(struct intel_crtc *crtc, struct intel_flip_work *work
local_irq_enable();



if (vgpu_active())
return;

here might look neater, and would still work with the additional error 
print that Maarten is going to add [1]


[1] https://patchwork.freedesktop.org/patch/141260/


if (crtc->debug.start_vbl_count &&
-   crtc->debug.start_vbl_count != end_vbl_count) {
+   crtc->debug.start_vbl_count != end_vbl_count &&
+!intel_vgpu_active(dev_priv)) {
DRM_ERROR("Atomic update failure on pipe %c (start=%u end=%u) time 
%lld us, min %d, max %d, scanline start %d, end %d\n",
  pipe_name(pipe), crtc->debug.start_vbl_count,
  end_vbl_count,
--
2.7.4

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


--
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: suppress atomic commit error message under gvt-g env

2017-03-05 Thread Zhi Wang

Hi Ville:
Thanks for the reply!  :P

Is this error message for the end-user or for debug? If this is for the 
end-user, only warning one time should be better? I saw a case on 
Celeron, if this happens, usually this would happen again and agin, the 
error message could fill all the dmesg. If this is only for debug, 
should DRM_DEBUG_KMS() would be better?


Anyway, thanks for the reply! :P

Thanks,
Zhi.

于 03/03/17 19:53, Ville Syrjälä 写道:

On Fri, Mar 03, 2017 at 10:56:16AM +0800, Zhi Wang wrote:

Can we directly use DRM_DEBUG_KMS() for this periodic error message?


No. We want to actually know when/if this fails.



On 03/03/17 19:53, bing@intel.com wrote:

From: Bing Niu 

under virtualization enviroment, it is possible guest update pipe
registers across vblank intervals due to overhead of mmio traps or vm
schedule out. However, it is safe since those pipe update happen in
virual registers and will not be committed to hardware. suppress that
atomic commit error message under virtualization case to avoid
confusing user.

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

diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index b16a295..5ce1ec6 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -158,6 +158,7 @@ void intel_pipe_update_end(struct intel_crtc *crtc, struct 
intel_flip_work *work
int scanline_end = intel_get_crtc_scanline(crtc);
u32 end_vbl_count = intel_crtc_get_vblank_counter(crtc);
ktime_t end_vbl_time = ktime_get();
+   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);

if (work) {
work->flip_queued_vblank = end_vbl_count;
@@ -184,7 +185,7 @@ void intel_pipe_update_end(struct intel_crtc *crtc, struct 
intel_flip_work *work
local_irq_enable();

if (crtc->debug.start_vbl_count &&
-   crtc->debug.start_vbl_count != end_vbl_count) {
+   crtc->debug.start_vbl_count != end_vbl_count && 
!intel_vgpu_active(dev_priv)) {
DRM_ERROR("Atomic update failure on pipe %c (start=%u end=%u) time 
%lld us, min %d, max %d, scanline start %d, end %d\n",
  pipe_name(pipe), crtc->debug.start_vbl_count,
  end_vbl_count,


___
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] [regression] Re: 4.11-rc0, thinkpad x220: GPU hang

2017-03-05 Thread Pavel Machek
Hi!

> > mplayer stopped working after a while. Dmesg says:
> > 
> > [ 3000.266533] cdc_ether 2-1.2:1.0 usb0: register 'cdc_ether' at

Now I'm pretty sure it is a regression in v4.11-rc0. Any ideas what to
try? Bisect will be slow and nasty :-(.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
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: Take rpm wakelock for releasing the fence on unbind (rev4)

2017-03-05 Thread Patchwork
== Series Details ==

Series: drm/i915: Take rpm wakelock for releasing the fence on unbind (rev4)
URL   : https://patchwork.freedesktop.org/series/20686/
State : success

== Summary ==

Series 20686v4 drm/i915: Take rpm wakelock for releasing the fence on unbind
https://patchwork.freedesktop.org/api/1.0/series/20686/revisions/4/mbox/

Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-a:
dmesg-fail -> PASS   (fi-ivb-3520m)
Subgroup hang-read-crc-pipe-b:
incomplete -> PASS   (fi-ivb-3520m)

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11 
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39 
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19 
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20 
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27 
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31 
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16 
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50 
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18 
fi-kbl-7500u total:278  pass:259  dwarn:1   dfail:0   fail:0   skip:18 
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17 
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18 
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10 
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28 
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29 

ec496685b4e7d90197d75d0cb7b98dfb0b90ac43 drm-tip: 2017y-03m-03d-22h-56m-33s UTC 
integration manifest
93427bb drm/i915: Take rpm wakelock for releasing the fence on unbind

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4066/
___
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: Take rpm wakelock for releasing the fence on unbind (rev2)

2017-03-05 Thread Patchwork
== Series Details ==

Series: drm/i915: Take rpm wakelock for releasing the fence on unbind (rev2)
URL   : https://patchwork.freedesktop.org/series/20686/
State : failure

== Summary ==

Series 20686v2 drm/i915: Take rpm wakelock for releasing the fence on unbind
https://patchwork.freedesktop.org/api/1.0/series/20686/revisions/2/mbox/

Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass   -> INCOMPLETE (fi-byt-n2820)
pass   -> INCOMPLETE (fi-kbl-7500u)
pass   -> INCOMPLETE (fi-skl-6770hq)
pass   -> INCOMPLETE (fi-bxt-t5700)
pass   -> INCOMPLETE (fi-hsw-4770)
pass   -> INCOMPLETE (fi-skl-6700k)
pass   -> INCOMPLETE (fi-snb-2520m)
pass   -> INCOMPLETE (fi-bdw-5557u)
pass   -> INCOMPLETE (fi-hsw-4770r)
pass   -> INCOMPLETE (fi-byt-j1900)
pass   -> INCOMPLETE (fi-snb-2600)
pass   -> INCOMPLETE (fi-skl-6700hq)
pass   -> INCOMPLETE (fi-bsw-n3050)
pass   -> INCOMPLETE (fi-bxt-j4205)
pass   -> INCOMPLETE (fi-ivb-3770)
pass   -> INCOMPLETE (fi-skl-6260u)
pass   -> INCOMPLETE (fi-ilk-650)
pass   -> INCOMPLETE (fi-ivb-3520m)

fi-bdw-5557u total:126  pass:122  dwarn:0   dfail:0   fail:0   skip:3  
fi-bsw-n3050 total:126  pass:113  dwarn:0   dfail:0   fail:0   skip:12 
fi-bxt-j4205 total:126  pass:114  dwarn:0   dfail:0   fail:0   skip:11 
fi-bxt-t5700 total:126  pass:113  dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-j1900 total:126  pass:113  dwarn:0   dfail:0   fail:0   skip:12 
fi-byt-n2820 total:126  pass:113  dwarn:0   dfail:0   fail:0   skip:12 
fi-hsw-4770  total:126  pass:117  dwarn:0   dfail:0   fail:0   skip:8  
fi-hsw-4770r total:126  pass:117  dwarn:0   dfail:0   fail:0   skip:8  
fi-ilk-650   total:126  pass:98   dwarn:0   dfail:0   fail:0   skip:27 
fi-ivb-3520m total:126  pass:113  dwarn:0   dfail:0   fail:0   skip:12 
fi-ivb-3770  total:126  pass:113  dwarn:0   dfail:0   fail:0   skip:12 
fi-kbl-7500u total:126  pass:113  dwarn:1   dfail:0   fail:0   skip:11 
fi-skl-6260u total:126  pass:122  dwarn:0   dfail:0   fail:0   skip:3  
fi-skl-6700hqtotal:126  pass:114  dwarn:0   dfail:0   fail:0   skip:11 
fi-skl-6700k total:126  pass:114  dwarn:0   dfail:0   fail:0   skip:11 
fi-skl-6770hqtotal:126  pass:122  dwarn:0   dfail:0   fail:0   skip:3  
fi-snb-2520m total:126  pass:109  dwarn:0   dfail:0   fail:0   skip:16 
fi-snb-2600  total:126  pass:109  dwarn:0   dfail:0   fail:0   skip:16 

ec496685b4e7d90197d75d0cb7b98dfb0b90ac43 drm-tip: 2017y-03m-03d-22h-56m-33s UTC 
integration manifest
f1fd994 drm/i915: Take rpm wakelock for releasing the fence on unbind

== Logs ==

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


[Intel-gfx] [PATCH v4] drm/i915: Take rpm wakelock for releasing the fence on unbind

2017-03-05 Thread Chris Wilson
Unbind the vma may happen at any time, outside of the normal GT wakeref.
As such it relies on having a wakeref of its own. However, we can forgo
clearing the register whilst the device is asleep and just mark it as
unused - so that when we do wake up the device, we will clear the unused
fence register (see i915_gem_restore_fences).

[22423.944631] WARNING: CPU: 3 PID: 26178 at 
drivers/gpu/drm/i915/intel_drv.h:1739 i915_vma_put_fence+0xf3/0x100 [i915]
[22423.946053] RPM wakelock ref not held during HW access
[22423.946056] Modules linked in: vgem(E) i915(E) nls_ascii(E) nls_cp437(E) 
vfat(E) fat(E) x86_pkg_temp_thermal(E) crct10dif_pclmul(E) crc32_pclmul(E) 
crc32c_intel(E) ghash_clmulni_intel(E) intel_gtt(E) i2c_algo_bit(E) 
drm_kms_helper(E) syscopyarea(E) sysfillrect(E) evdev(E) aesni_intel(E) 
aes_x86_64(E) crypto_simd(E) cryptd(E) glue_helper(E) sysimgblt(E) 
fb_sys_fops(E) prime_numbers(E) drm(E) efivars(E) mei_me(E) lpc_ich(E) mei(E) 
mfd_core(E) battery(E) video(E) acpi_pad(E) button(E) tpm_tis(E) 
tpm_tis_core(E) tpm(E) autofs4(E) i2c_i801(E) thermal(E) fan(E) 
i2c_designware_platform(E) i2c_designware_core(E)
[22423.946438] CPU: 2 PID: 26178 Comm: gem_concurrent_ Tainted: GE  
 4.10.0+ #101
[22423.946513] Hardware name: � 
�/�, BIOS 
RYBDWi35.86A.0246.2
[22423.946600] Call Trace:
[22423.946641]  dump_stack+0x68/0x9f
[22423.946703]  __warn+0x107/0x130
[22423.946763]  warn_slowpath_fmt+0xa8/0xe0
[22423.946825]  ? __warn+0x130/0x130
[22423.946868]  ? free_hot_cold_page_list+0x53/0x70
[22423.946942]  ? mark_lock+0xcc/0x7f0
[22423.946997]  ? __lock_is_held+0x84/0x100
[22423.947115]  ? i915_vma_put_fence+0x64/0x100 [i915]
[22423.947224]  i915_vma_put_fence+0xf3/0x100 [i915]
[22423.947335]  i915_vma_unbind+0x4da/0x560 [i915]
[22423.947387]  ? rb_erase+0x812/0x8a0
[22423.947439]  ? kfree+0xa2/0xd0
[22423.947562]  i915_vma_close+0x159/0x180 [i915]
[22423.947674]  intel_ring_free+0x31/0x50 [i915]
[22423.947776]  i915_gem_context_free+0x1ff/0x3d0 [i915]
[22423.947887]  context_close+0x106/0x110 [i915]
[22423.947989]  context_idr_cleanup+0xc/0x10 [i915]
[22423.948041]  idr_for_each+0x14d/0x1d0
[22423.948158]  ? context_close+0x110/0x110 [i915]
[22423.948206]  ? get_from_free_list+0x70/0x70
[22423.948261]  ? __lock_is_held+0x84/0x100
[22423.948325]  ? __mutex_unlock_slowpath+0xd4/0x400
[22423.948448]  i915_gem_context_close+0x4b/0x90 [i915]
[22423.948544]  i915_driver_preclose+0x28/0x50 [i915]
[22423.948620]  drm_release+0x175/0x690 [drm]
[22423.948681]  ? fcntl_setlk+0x5e0/0x5e0
[22423.948746]  __fput+0x17d/0x300
[22423.948807]  fput+0x9/0x10
[22423.948859]  task_work_run+0xa7/0xe0
[22423.948924]  do_exit+0x4d2/0x13e0
[22423.948986]  ? mm_update_next_owner+0x320/0x320
[22423.949051]  ? __do_page_fault+0x209/0x5c0
[22423.949110]  ? mark_held_locks+0x23/0xc0
[22423.949166]  ? entry_SYSCALL_64_fastpath+0x5/0xb1
[22423.949232]  do_group_exit+0x93/0x160
[22423.949289]  SyS_exit_group+0x18/0x20
[22423.949350]  entry_SYSCALL_64_fastpath+0x1c/0xb1
[22423.949403] RIP: 0033:0x7f9cc2e154c8
[22423.949484] RSP: 002b:7ffd7e81b448 EFLAGS: 0246 ORIG_RAX: 
00e7
[22423.949557] RAX: ffda RBX: 810ef1f0 RCX: 7f9cc2e154c8
[22423.949617] RDX:  RSI: 003c RDI: 
[22423.949677] RBP: 880367e9ff98 R08: 00e7 R09: ff88
[22423.949741] R10: 7f9cc1d5c000 R11: 0246 R12: 7f9cc30f6c30
[22423.949798] R13:  R14: 7f9cc30f6c20 R15: 0003
[22423.949868]  ? trace_hardirqs_off_caller+0xc0/0x110

v2: Move the rpm check down a layer so that we still perform the
vma/fence update required for the deferred mmio write on resume.
v3: Don't touch i915_gem_object_set_cache_level() and leave the rpm to
the low level routines (such as i915_vma_put_fence).
v4: vma may be null in fence_write, so extract drm_i915_private from
fence->i915

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem_fence_reg.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_fence_reg.c 
b/drivers/gpu/drm/i915/i915_gem_fence_reg.c
index fadbe8f4c745..5fe2cd8c8f28 100644
--- a/drivers/gpu/drm/i915/i915_gem_fence_reg.c
+++ b/drivers/gpu/drm/i915/i915_gem_fence_reg.c
@@ -248,7 +248,14 @@ static int fence_update(struct drm_i915_fence_reg *fence,
list_move(>link, >i915->mm.fence_list);
}
 
-   fence_write(fence, vma);
+   /* We only need to update the register itself if the device is awake.
+* If the device is currently powered down, we will defer the write
+* to the runtime resume, see i915_gem_restore_fences().
+*/
+   if (intel_runtime_pm_get_if_in_use(fence->i915)) {
+   fence_write(fence, vma);
+   intel_runtime_pm_put(fence->i915);
+   

[Intel-gfx] [PATCH v3] drm/i915: Take rpm wakelock for releasing the fence on unbind

2017-03-05 Thread Chris Wilson
Unbind the vma may happen at any time, outside of the normal GT wakeref.
As such it relies on having a wakeref of its own. However, we can forgo
clearing the register whilst the device is asleep and just mark it as
unused - so that when we do wake up the device, we will clear the unused
fence register (see i915_gem_restore_fences).

[22423.944631] WARNING: CPU: 3 PID: 26178 at 
drivers/gpu/drm/i915/intel_drv.h:1739 i915_vma_put_fence+0xf3/0x100 [i915]
[22423.946053] RPM wakelock ref not held during HW access
[22423.946056] Modules linked in: vgem(E) i915(E) nls_ascii(E) nls_cp437(E) 
vfat(E) fat(E) x86_pkg_temp_thermal(E) crct10dif_pclmul(E) crc32_pclmul(E) 
crc32c_intel(E) ghash_clmulni_intel(E) intel_gtt(E) i2c_algo_bit(E) 
drm_kms_helper(E) syscopyarea(E) sysfillrect(E) evdev(E) aesni_intel(E) 
aes_x86_64(E) crypto_simd(E) cryptd(E) glue_helper(E) sysimgblt(E) 
fb_sys_fops(E) prime_numbers(E) drm(E) efivars(E) mei_me(E) lpc_ich(E) mei(E) 
mfd_core(E) battery(E) video(E) acpi_pad(E) button(E) tpm_tis(E) 
tpm_tis_core(E) tpm(E) autofs4(E) i2c_i801(E) thermal(E) fan(E) 
i2c_designware_platform(E) i2c_designware_core(E)
[22423.946438] CPU: 2 PID: 26178 Comm: gem_concurrent_ Tainted: GE  
 4.10.0+ #101
[22423.946513] Hardware name: � 
�/�, BIOS 
RYBDWi35.86A.0246.2
[22423.946600] Call Trace:
[22423.946641]  dump_stack+0x68/0x9f
[22423.946703]  __warn+0x107/0x130
[22423.946763]  warn_slowpath_fmt+0xa8/0xe0
[22423.946825]  ? __warn+0x130/0x130
[22423.946868]  ? free_hot_cold_page_list+0x53/0x70
[22423.946942]  ? mark_lock+0xcc/0x7f0
[22423.946997]  ? __lock_is_held+0x84/0x100
[22423.947115]  ? i915_vma_put_fence+0x64/0x100 [i915]
[22423.947224]  i915_vma_put_fence+0xf3/0x100 [i915]
[22423.947335]  i915_vma_unbind+0x4da/0x560 [i915]
[22423.947387]  ? rb_erase+0x812/0x8a0
[22423.947439]  ? kfree+0xa2/0xd0
[22423.947562]  i915_vma_close+0x159/0x180 [i915]
[22423.947674]  intel_ring_free+0x31/0x50 [i915]
[22423.947776]  i915_gem_context_free+0x1ff/0x3d0 [i915]
[22423.947887]  context_close+0x106/0x110 [i915]
[22423.947989]  context_idr_cleanup+0xc/0x10 [i915]
[22423.948041]  idr_for_each+0x14d/0x1d0
[22423.948158]  ? context_close+0x110/0x110 [i915]
[22423.948206]  ? get_from_free_list+0x70/0x70
[22423.948261]  ? __lock_is_held+0x84/0x100
[22423.948325]  ? __mutex_unlock_slowpath+0xd4/0x400
[22423.948448]  i915_gem_context_close+0x4b/0x90 [i915]
[22423.948544]  i915_driver_preclose+0x28/0x50 [i915]
[22423.948620]  drm_release+0x175/0x690 [drm]
[22423.948681]  ? fcntl_setlk+0x5e0/0x5e0
[22423.948746]  __fput+0x17d/0x300
[22423.948807]  fput+0x9/0x10
[22423.948859]  task_work_run+0xa7/0xe0
[22423.948924]  do_exit+0x4d2/0x13e0
[22423.948986]  ? mm_update_next_owner+0x320/0x320
[22423.949051]  ? __do_page_fault+0x209/0x5c0
[22423.949110]  ? mark_held_locks+0x23/0xc0
[22423.949166]  ? entry_SYSCALL_64_fastpath+0x5/0xb1
[22423.949232]  do_group_exit+0x93/0x160
[22423.949289]  SyS_exit_group+0x18/0x20
[22423.949350]  entry_SYSCALL_64_fastpath+0x1c/0xb1
[22423.949403] RIP: 0033:0x7f9cc2e154c8
[22423.949484] RSP: 002b:7ffd7e81b448 EFLAGS: 0246 ORIG_RAX: 
00e7
[22423.949557] RAX: ffda RBX: 810ef1f0 RCX: 7f9cc2e154c8
[22423.949617] RDX:  RSI: 003c RDI: 
[22423.949677] RBP: 880367e9ff98 R08: 00e7 R09: ff88
[22423.949741] R10: 7f9cc1d5c000 R11: 0246 R12: 7f9cc30f6c30
[22423.949798] R13:  R14: 7f9cc30f6c20 R15: 0003
[22423.949868]  ? trace_hardirqs_off_caller+0xc0/0x110

v2: Move the rpm check down a layer so that we still perform the
vma/fence update required for the deferred mmio write on resume.
v3: Don't touch i915_gem_object_set_cache_level() and leave the rpm to
the low level routines (such as i915_vma_put_fence).

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem_fence_reg.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_fence_reg.c 
b/drivers/gpu/drm/i915/i915_gem_fence_reg.c
index fadbe8f4c745..36687f5320ce 100644
--- a/drivers/gpu/drm/i915/i915_gem_fence_reg.c
+++ b/drivers/gpu/drm/i915/i915_gem_fence_reg.c
@@ -248,7 +248,14 @@ static int fence_update(struct drm_i915_fence_reg *fence,
list_move(>link, >i915->mm.fence_list);
}
 
-   fence_write(fence, vma);
+   /* We only need to update the register itself if the device is awake.
+* If the device is currently powered down, we will defer the write
+* to the runtime resume, see i915_gem_restore_fences().
+*/
+   if (intel_runtime_pm_get_if_in_use(vma->vm->i915)) {
+   fence_write(fence, vma);
+   intel_runtime_pm_put(vma->vm->i915);
+   }
 
if (vma) {
if (fence->vma != vma) {
@@ 

[Intel-gfx] [PATCH v2] drm/i915: Take rpm wakelock for releasing the fence on unbind

2017-03-05 Thread Chris Wilson
Unbind the vma may happen at any time, outside of the normal GT wakeref.
As such it relies on having a wakeref of its own. However, we can forgo
clearing the register whilst the device is asleep and just mark it as
unused - so that when we do wake up the device, we will clear the unused
fence register (see i915_gem_restore_fences).

[22423.944631] WARNING: CPU: 3 PID: 26178 at 
drivers/gpu/drm/i915/intel_drv.h:1739 i915_vma_put_fence+0xf3/0x100 [i915]
[22423.946053] RPM wakelock ref not held during HW access
[22423.946056] Modules linked in: vgem(E) i915(E) nls_ascii(E) nls_cp437(E) 
vfat(E) fat(E) x86_pkg_temp_thermal(E) crct10dif_pclmul(E) crc32_pclmul(E) 
crc32c_intel(E) ghash_clmulni_intel(E) intel_gtt(E) i2c_algo_bit(E) 
drm_kms_helper(E) syscopyarea(E) sysfillrect(E) evdev(E) aesni_intel(E) 
aes_x86_64(E) crypto_simd(E) cryptd(E) glue_helper(E) sysimgblt(E) 
fb_sys_fops(E) prime_numbers(E) drm(E) efivars(E) mei_me(E) lpc_ich(E) mei(E) 
mfd_core(E) battery(E) video(E) acpi_pad(E) button(E) tpm_tis(E) 
tpm_tis_core(E) tpm(E) autofs4(E) i2c_i801(E) thermal(E) fan(E) 
i2c_designware_platform(E) i2c_designware_core(E)
[22423.946438] CPU: 2 PID: 26178 Comm: gem_concurrent_ Tainted: GE  
 4.10.0+ #101
[22423.946513] Hardware name: � 
�/�, BIOS 
RYBDWi35.86A.0246.2
[22423.946600] Call Trace:
[22423.946641]  dump_stack+0x68/0x9f
[22423.946703]  __warn+0x107/0x130
[22423.946763]  warn_slowpath_fmt+0xa8/0xe0
[22423.946825]  ? __warn+0x130/0x130
[22423.946868]  ? free_hot_cold_page_list+0x53/0x70
[22423.946942]  ? mark_lock+0xcc/0x7f0
[22423.946997]  ? __lock_is_held+0x84/0x100
[22423.947115]  ? i915_vma_put_fence+0x64/0x100 [i915]
[22423.947224]  i915_vma_put_fence+0xf3/0x100 [i915]
[22423.947335]  i915_vma_unbind+0x4da/0x560 [i915]
[22423.947387]  ? rb_erase+0x812/0x8a0
[22423.947439]  ? kfree+0xa2/0xd0
[22423.947562]  i915_vma_close+0x159/0x180 [i915]
[22423.947674]  intel_ring_free+0x31/0x50 [i915]
[22423.947776]  i915_gem_context_free+0x1ff/0x3d0 [i915]
[22423.947887]  context_close+0x106/0x110 [i915]
[22423.947989]  context_idr_cleanup+0xc/0x10 [i915]
[22423.948041]  idr_for_each+0x14d/0x1d0
[22423.948158]  ? context_close+0x110/0x110 [i915]
[22423.948206]  ? get_from_free_list+0x70/0x70
[22423.948261]  ? __lock_is_held+0x84/0x100
[22423.948325]  ? __mutex_unlock_slowpath+0xd4/0x400
[22423.948448]  i915_gem_context_close+0x4b/0x90 [i915]
[22423.948544]  i915_driver_preclose+0x28/0x50 [i915]
[22423.948620]  drm_release+0x175/0x690 [drm]
[22423.948681]  ? fcntl_setlk+0x5e0/0x5e0
[22423.948746]  __fput+0x17d/0x300
[22423.948807]  fput+0x9/0x10
[22423.948859]  task_work_run+0xa7/0xe0
[22423.948924]  do_exit+0x4d2/0x13e0
[22423.948986]  ? mm_update_next_owner+0x320/0x320
[22423.949051]  ? __do_page_fault+0x209/0x5c0
[22423.949110]  ? mark_held_locks+0x23/0xc0
[22423.949166]  ? entry_SYSCALL_64_fastpath+0x5/0xb1
[22423.949232]  do_group_exit+0x93/0x160
[22423.949289]  SyS_exit_group+0x18/0x20
[22423.949350]  entry_SYSCALL_64_fastpath+0x1c/0xb1
[22423.949403] RIP: 0033:0x7f9cc2e154c8
[22423.949484] RSP: 002b:7ffd7e81b448 EFLAGS: 0246 ORIG_RAX: 
00e7
[22423.949557] RAX: ffda RBX: 810ef1f0 RCX: 7f9cc2e154c8
[22423.949617] RDX:  RSI: 003c RDI: 
[22423.949677] RBP: 880367e9ff98 R08: 00e7 R09: ff88
[22423.949741] R10: 7f9cc1d5c000 R11: 0246 R12: 7f9cc30f6c30
[22423.949798] R13:  R14: 7f9cc30f6c20 R15: 0003
[22423.949868]  ? trace_hardirqs_off_caller+0xc0/0x110

v2: Move the rpm check down a layer so that we still perform the
vma/fence update required for the deferred mmio write on resume.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem.c   |  4 
 drivers/gpu/drm/i915/i915_gem_fence_reg.c | 11 ---
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d3b432541984..d247ba28fcca 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3205,6 +3205,8 @@ int i915_gem_object_set_cache_level(struct 
drm_i915_gem_object *obj,
if (ret)
return ret;
 
+   intel_runtime_pm_get(to_i915(obj->base.dev));
+
if (!HAS_LLC(to_i915(obj->base.dev)) &&
cache_level != I915_CACHE_NONE) {
/* Access to snoopable pages through the GTT is
@@ -3246,6 +3248,8 @@ int i915_gem_object_set_cache_level(struct 
drm_i915_gem_object *obj,
if (ret)
return ret;
}
+
+   intel_runtime_pm_put(to_i915(obj->base.dev));
}
 
if (obj->base.write_domain == I915_GEM_DOMAIN_CPU &&
diff --git 

[Intel-gfx] [PATCH] drm/i915: Take rpm wakelock for releasing the fence on unbind

2017-03-05 Thread Chris Wilson
Unbind the vma may happen at any time, outside of the normal GT wakeref.
As such it relies on having a wakeref of its own. However, we can forgo
clearing the register whilst the device is asleep and just mark it as
unused - so that when we do wake up the device, we will clear the unused
fence register (see i915_gem_restore_fences).

[22423.944631] WARNING: CPU: 3 PID: 26178 at 
drivers/gpu/drm/i915/intel_drv.h:1739 i915_vma_put_fence+0xf3/0x100 [i915]
[22423.946053] RPM wakelock ref not held during HW access
[22423.946056] Modules linked in: vgem(E) i915(E) nls_ascii(E) nls_cp437(E) 
vfat(E) fat(E) x86_pkg_temp_thermal(E) crct10dif_pclmul(E) crc32_pclmul(E) 
crc32c_intel(E) ghash_clmulni_intel(E) intel_gtt(E) i2c_algo_bit(E) 
drm_kms_helper(E) syscopyarea(E) sysfillrect(E) evdev(E) aesni_intel(E) 
aes_x86_64(E) crypto_simd(E) cryptd(E) glue_helper(E) sysimgblt(E) 
fb_sys_fops(E) prime_numbers(E) drm(E) efivars(E) mei_me(E) lpc_ich(E) mei(E) 
mfd_core(E) battery(E) video(E) acpi_pad(E) button(E) tpm_tis(E) 
tpm_tis_core(E) tpm(E) autofs4(E) i2c_i801(E) thermal(E) fan(E) 
i2c_designware_platform(E) i2c_designware_core(E)
[22423.946438] CPU: 2 PID: 26178 Comm: gem_concurrent_ Tainted: GE  
 4.10.0+ #101
[22423.946513] Hardware name: � 
�/�, BIOS 
RYBDWi35.86A.0246.2
[22423.946600] Call Trace:
[22423.946641]  dump_stack+0x68/0x9f
[22423.946703]  __warn+0x107/0x130
[22423.946763]  warn_slowpath_fmt+0xa8/0xe0
[22423.946825]  ? __warn+0x130/0x130
[22423.946868]  ? free_hot_cold_page_list+0x53/0x70
[22423.946942]  ? mark_lock+0xcc/0x7f0
[22423.946997]  ? __lock_is_held+0x84/0x100
[22423.947115]  ? i915_vma_put_fence+0x64/0x100 [i915]
[22423.947224]  i915_vma_put_fence+0xf3/0x100 [i915]
[22423.947335]  i915_vma_unbind+0x4da/0x560 [i915]
[22423.947387]  ? rb_erase+0x812/0x8a0
[22423.947439]  ? kfree+0xa2/0xd0
[22423.947562]  i915_vma_close+0x159/0x180 [i915]
[22423.947674]  intel_ring_free+0x31/0x50 [i915]
[22423.947776]  i915_gem_context_free+0x1ff/0x3d0 [i915]
[22423.947887]  context_close+0x106/0x110 [i915]
[22423.947989]  context_idr_cleanup+0xc/0x10 [i915]
[22423.948041]  idr_for_each+0x14d/0x1d0
[22423.948158]  ? context_close+0x110/0x110 [i915]
[22423.948206]  ? get_from_free_list+0x70/0x70
[22423.948261]  ? __lock_is_held+0x84/0x100
[22423.948325]  ? __mutex_unlock_slowpath+0xd4/0x400
[22423.948448]  i915_gem_context_close+0x4b/0x90 [i915]
[22423.948544]  i915_driver_preclose+0x28/0x50 [i915]
[22423.948620]  drm_release+0x175/0x690 [drm]
[22423.948681]  ? fcntl_setlk+0x5e0/0x5e0
[22423.948746]  __fput+0x17d/0x300
[22423.948807]  fput+0x9/0x10
[22423.948859]  task_work_run+0xa7/0xe0
[22423.948924]  do_exit+0x4d2/0x13e0
[22423.948986]  ? mm_update_next_owner+0x320/0x320
[22423.949051]  ? __do_page_fault+0x209/0x5c0
[22423.949110]  ? mark_held_locks+0x23/0xc0
[22423.949166]  ? entry_SYSCALL_64_fastpath+0x5/0xb1
[22423.949232]  do_group_exit+0x93/0x160
[22423.949289]  SyS_exit_group+0x18/0x20
[22423.949350]  entry_SYSCALL_64_fastpath+0x1c/0xb1
[22423.949403] RIP: 0033:0x7f9cc2e154c8
[22423.949484] RSP: 002b:7ffd7e81b448 EFLAGS: 0246 ORIG_RAX: 
00e7
[22423.949557] RAX: ffda RBX: 810ef1f0 RCX: 7f9cc2e154c8
[22423.949617] RDX:  RSI: 003c RDI: 
[22423.949677] RBP: 880367e9ff98 R08: 00e7 R09: ff88
[22423.949741] R10: 7f9cc1d5c000 R11: 0246 R12: 7f9cc30f6c30
[22423.949798] R13:  R14: 7f9cc30f6c20 R15: 0003
[22423.949868]  ? trace_hardirqs_off_caller+0xc0/0x110

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem.c   |  4 
 drivers/gpu/drm/i915/i915_gem_fence_reg.c | 11 ---
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d3b432541984..d247ba28fcca 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3205,6 +3205,8 @@ int i915_gem_object_set_cache_level(struct 
drm_i915_gem_object *obj,
if (ret)
return ret;
 
+   intel_runtime_pm_get(to_i915(obj->base.dev));
+
if (!HAS_LLC(to_i915(obj->base.dev)) &&
cache_level != I915_CACHE_NONE) {
/* Access to snoopable pages through the GTT is
@@ -3246,6 +3248,8 @@ int i915_gem_object_set_cache_level(struct 
drm_i915_gem_object *obj,
if (ret)
return ret;
}
+
+   intel_runtime_pm_put(to_i915(obj->base.dev));
}
 
if (obj->base.write_domain == I915_GEM_DOMAIN_CPU &&
diff --git a/drivers/gpu/drm/i915/i915_gem_fence_reg.c 
b/drivers/gpu/drm/i915/i915_gem_fence_reg.c
index fadbe8f4c745..0ea6092d67c7 100644
---