Re: [Intel-gfx] [PATCH 5/8] drm/i915: Add a atomic evasion step to watermark programming.

[Maarten Lankhorst]

Hey,

Op 20-10-16 om 01:15 schreef Matt Roper:
> On Wed, Oct 12, 2016 at 03:28:18PM +0200, Maarten Lankhorst wrote:
>> Allow the driver to write watermarks during atomic evasion.
>> This will make it possible to write the watermarks in a cleaner
>> way on gen9+.
>>
>> Signed-off-by: Maarten Lankhorst 
>> ---
>>  drivers/gpu/drm/i915/i915_drv.h  |  6 --
>>  drivers/gpu/drm/i915/intel_display.c | 18 --
>>  drivers/gpu/drm/i915/intel_pm.c  | 19 +--
>>  3 files changed, 29 insertions(+), 14 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h 
>> b/drivers/gpu/drm/i915/i915_drv.h
>> index f65ccf9b0bea..09588c58148f 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -484,6 +484,7 @@ struct sdvo_device_mapping {
>>  
>>  struct intel_connector;
>>  struct intel_encoder;
>> +struct intel_atomic_state;
>>  struct intel_crtc_state;
>>  struct intel_initial_plane_config;
>>  struct intel_crtc;
>> @@ -497,8 +498,9 @@ struct drm_i915_display_funcs {
>>  int (*compute_intermediate_wm)(struct drm_device *dev,
>> struct intel_crtc *intel_crtc,
>> struct intel_crtc_state *newstate);
>> -void (*initial_watermarks)(struct intel_crtc_state *cstate);
>> -void (*optimize_watermarks)(struct intel_crtc_state *cstate);
>> +void (*initial_watermarks)(struct intel_atomic_state *state, struct 
>> intel_crtc_state *cstate);
>> +void (*atomic_evade_watermarks)(struct intel_atomic_state *state, 
>> struct intel_crtc_state *cstate);
>> +void (*optimize_watermarks)(struct intel_atomic_state *state, struct 
>> intel_crtc_state *cstate);
> initial_watermarks() and optimize_watermarks() are currently only used
> on ILK (and possibly by in-development VLV/CHV patches that Ville is
> working on?).  As far as I can see, the top-level state that we add as a
> parameter here doesn't actually get used in the implementations.  Are
> you adding it to just make them more similar to the signature of the new
> atomic_evade_watermarks vfunc or did you have something else in mind?
>
> I'd also suggest adding a brief comment to your new skl_evade_crtc_wm()
> function that indicates that nearly all of the gen9 watermark values are
> per-plane values that get written as part of the general plane update in
> skylake_update_primary_plane and/or skl_update_plane.  Given that those
> two functions are located in other files that may help clarify to future
> developers why this function appears so trivial.

We don't completely use intel_atomic_state here yet, patch 7 uses it for the
ddb allocation and because initial_watermarks ends up calling
.atomic_evade_watermarks().

I added intel_atomic_state to all callbacks to keep the function signature
identical. It looked better to me to put the function signature in a small
change, and then the behavioral change in patch 7 separately, for easier
bisection.

~Maarten

___
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/vgem_basic: Retry the initial module unload in unload test

[Daniel Vetter]

On Tue, Oct 18, 2016 at 01:48:52PM +0100, Chris Wilson wrote:
> On Tue, Oct 18, 2016 at 03:41:54PM +0300, Petri Latvala wrote:
> > How should vgem work be flushed properly? With this i915 flushing is
> > guaranteed even if vgem is opened first, then i915, but such
> > flushing won't be done if only vgem is opened (I see only vgem_slow
> > doing that)...
> 
> vgem doesn't have the same delayed close as i915. For vgem, closing the
> fd (i.e. on process exit) will first signal all fences and drop
> references for that fd, so effectively all work will be completed. The
> external references to the vgem.ko's object (via dma-buf) will only
> exist if they were constructed by the test and if they were, e.g. i915,
> they too should be will be flushed by igt in its exithandlers.
> 
> Other drivers may have similar bridges to cross ofc.

One long-term caveat is that exit handlers only run on final exit, not
after each subtest. Atm that's no issue because we run each subtest in
isolation. But I think that for throughput reasons (some of the testcases
run _much_ faster if you just launch the binary once, due to fairly heavy
overhead in igt_fixtures) we can't rely on that forever.

Mostly thinking of high-throughput complete test runs here.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Handle early failure during intel_get_load_detect_pipe

[Daniel Vetter]

On Wed, Oct 19, 2016 at 06:55:44PM +0100, Chris Wilson wrote:
> On Wed, Oct 19, 2016 at 05:47:39PM -, Patchwork wrote:
> > == Series Details ==
> > 
> > Series: drm/i915: Handle early failure during intel_get_load_detect_pipe
> > URL   : https://patchwork.freedesktop.org/series/14016/
> > State : warning
> > 
> > == Summary ==
> > 
> > Series 14016v1 drm/i915: Handle early failure during 
> > intel_get_load_detect_pipe
> > https://patchwork.freedesktop.org/api/1.0/series/14016/revisions/1/mbox/
> > 
> > Test drv_module_reload_basic:
> > pass   -> DMESG-WARN (fi-skl-6700hq)
> > Test gem_exec_suspend:
> > Subgroup basic-s3:
> > dmesg-warn -> PASS   (fi-skl-6700hq)
> > Test kms_cursor_legacy:
> > Subgroup basic-busy-flip-before-cursor-legacy:
> > pass   -> DMESG-WARN (fi-ilk-650)
> > Test kms_force_connector_basic:
> > Subgroup force-load-detect:
> > incomplete -> PASS   (fi-byt-j1900)
> > Test kms_pipe_crc_basic:
> > Subgroup suspend-read-crc-pipe-a:
> > dmesg-warn -> PASS   (fi-skl-6700hq)
> > Subgroup suspend-read-crc-pipe-b:
> > dmesg-warn -> PASS   (fi-skl-6700hq)
> > incomplete -> PASS   (fi-snb-2600)
> > Subgroup suspend-read-crc-pipe-c:
> > dmesg-warn -> PASS   (fi-skl-6700hq)
> > 
> > fi-ilk-650   total:246  pass:159  dwarn:25  dfail:0   fail:2   skip:60 
> 
> All the warns are in -nightly, give or take piglit sporadicly assigning the
> unrelated warns to individual tests. Too bad it didn't list all the
> notrun -> pass, or still doesn't mention the actual oops on
> fi-ivb-3720m.
> 
> Looks like we don't have a backmerge yet, so this needs to be applied to
> drm-misc.

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

Re: [Intel-gfx] gvt gem fixes

[Daniel Vetter]

On Thu, Oct 20, 2016 at 08:33:05AM +0800, Zhenyu Wang wrote:
> On 2016.10.19 12:02:58 +0100, Chris Wilson wrote:
> > On Wed, Oct 19, 2016 at 06:45:51PM +0800, Zhenyu Wang wrote:
> > > On 2016.10.19 11:11:35 +0100, Chris Wilson wrote:
> > > > I think this is the set required to bring gvt into line, at least to
> > > > unblock myself.
> > > 
> > > Thanks a lot, Chris. I'd like to merge this in next pull request,
> > > or let me know you want to be picked up by drm-intel directly.
> > > If 4/12 would be picked up alone, I'll skip that one in gvt tree.
> > 
> > If you are confident in having the pull ready in the next day or so,
> > I'll just preface my series with these and they will evaporate after the
> > merge.
> >
> 
> I'll try to send it today.
> 
> > I'll apply 4/12 right now to get that out of the way.
> 
> ok, fine.

Yeah, I think anything that touches i915 code should get merged through
drm-intel directly with the usual process. Only exception is when gvt has
a functional depency and it's a small patch, then I think we can sometimes
merge i915 core patches through gvt, with an ack from Jani or me (and
still proper review and CI and everything ofc). But that should be the
rare exception.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] gvt gem fixes

[Zhenyu Wang]

On 2016.10.20 09:02:45 +0200, Daniel Vetter wrote:
> Yeah, I think anything that touches i915 code should get merged through
> drm-intel directly with the usual process. Only exception is when gvt has
> a functional depency and it's a small patch, then I think we can sometimes
> merge i915 core patches through gvt, with an ack from Jani or me (and
> still proper review and CI and everything ofc). But that should be the
> rare exception.

That's fair enough for me. One prepared change is to fix gvt header
issue you've listed. As it touches intel_gvt.h in i915, I'll send that
seperately first 
(https://github.com/01org/gvt-linux/commit/b6a1ca7571ae45186394e555dc420481c1a9dba5)

-- 
Open Source Technology Center, Intel ltd.

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


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

Re: [Intel-gfx] [PATCH 5/7] drm/i915: Update kerneldoc for intel_dpll_mgr.c

[Daniel Vetter]

On Wed, Oct 19, 2016 at 06:29:13PM +0300, Jani Nikula wrote:
> On Wed, 19 Oct 2016, Ander Conselvan De Oliveira  wrote:
> > On Thu, 2016-10-13 at 15:46 +0200, Daniel Vetter wrote:
> >> > +/**
> >> > + * @hw_state: hardware configuration for the DPLL.
> >> "... stored in struct _dpll_hw_state." - I love my hyperlinks ;-)
> >
> > I'll add that, but I think it's silly. The type of the field is struct
> > intel_dpll_hw_state, so I think it would be more natural if the 
> > documentation
> > tool would add that link automatically.
> 
> Agreed.

Someone volunteering? I'd hope it would be at most a bit of shuffling with
the generator, we should have the type and all that handy already. Except
maybe lots of corner-cases ...

And ack on the struct layout bikeshed I had.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 07/12] drm/i915/gvt: Hold a reference on the request

[Chris Wilson]

On Thu, Oct 20, 2016 at 08:22:00AM +0800, Zhenyu Wang wrote:
> On 2016.10.19 11:11:42 +0100, Chris Wilson wrote:
> > The workload took a pointer to the request, and even waited upon,
> > without holding a reference on the request. Take that reference
> > explicitly and fix up the error path following request allocation that
> > missed flushing the request.
> > 
> > Signed-off-by: Chris Wilson 
> > ---
> >  drivers/gpu/drm/i915/gvt/scheduler.c | 24 +---
> >  1 file changed, 13 insertions(+), 11 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
> > b/drivers/gpu/drm/i915/gvt/scheduler.c
> > index b15cdf5978a9..224f19ae61ab 100644
> > --- a/drivers/gpu/drm/i915/gvt/scheduler.c
> > +++ b/drivers/gpu/drm/i915/gvt/scheduler.c
> > @@ -163,6 +163,7 @@ static int dispatch_workload(struct intel_vgpu_workload 
> > *workload)
> > int ring_id = workload->ring_id;
> > struct i915_gem_context *shadow_ctx = workload->vgpu->shadow_ctx;
> > struct drm_i915_private *dev_priv = workload->vgpu->gvt->dev_priv;
> > +   struct drm_i915_gem_request *rq;
> > int ret;
> >  
> > gvt_dbg_sched("ring id %d prepare to dispatch workload %p\n",
> > @@ -171,17 +172,16 @@ static int dispatch_workload(struct 
> > intel_vgpu_workload *workload)
> > shadow_ctx->desc_template = workload->ctx_desc.addressing_mode <<
> > GEN8_CTX_ADDRESSING_MODE_SHIFT;
> >  
> > -   workload->req = i915_gem_request_alloc(dev_priv->engine[ring_id],
> > -  shadow_ctx);
> > -   if (IS_ERR_OR_NULL(workload->req)) {
> > +   rq = i915_gem_request_alloc(dev_priv->engine[ring_id], shadow_ctx);
> > +   if (IS_ERR(rq)) {
> > gvt_err("fail to allocate gem request\n");
> > -   workload->status = PTR_ERR(workload->req);
> > -   workload->req = NULL;
> > +   workload->status = PTR_ERR(rq);
> > return workload->status;
> > }
> >  
> > -   gvt_dbg_sched("ring id %d get i915 gem request %p\n",
> > -   ring_id, workload->req);
> > +   gvt_dbg_sched("ring id %d get i915 gem request %p\n", ring_id, rq);
> > +
> > +   workload->req = i915_gem_request_get(rq);
> >  
> > mutex_lock(>lock);
> >  
> > @@ -208,16 +208,16 @@ static int dispatch_workload(struct 
> > intel_vgpu_workload *workload)
> > gvt_dbg_sched("ring id %d submit workload to i915 %p\n",
> > ring_id, workload->req);
> >  
> > -   i915_add_request_no_flush(workload->req);
> > -
> > +   i915_add_request_no_flush(rq);
> > workload->dispatched = true;
> > return 0;
> >  err:
> > workload->status = ret;
> > -   if (workload->req)
> > -   workload->req = NULL;
> > +   i915_gem_request_put(fetch_and_zero(>req));
> >
> 
> Looks we don't need put here as in error path from dispatch_workload()
> we will go with below put path too in main thread.

If we clear the request pointer, then we need the put. But yes, we don't
necessarily need to clear the pointer on error for the caller, as the
caller doesn't distinguish the error path and the no-op request can be
handled identically to a real request.
-Chris

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

Re: [Intel-gfx] [PATCH 10/10] mm: replace access_process_vm() write parameter with gup_flags

[Michael Ellerman]

Lorenzo Stoakes  writes:

> diff --git a/arch/powerpc/kernel/ptrace32.c b/arch/powerpc/kernel/ptrace32.c
> index f52b7db3..010b7b3 100644
> --- a/arch/powerpc/kernel/ptrace32.c
> +++ b/arch/powerpc/kernel/ptrace32.c
> @@ -74,7 +74,7 @@ long compat_arch_ptrace(struct task_struct *child, 
> compat_long_t request,
>   break;
>  
>   copied = access_process_vm(child, (u64)addrOthers, ,
> - sizeof(tmp), 0);
> + sizeof(tmp), FOLL_FORCE);
>   if (copied != sizeof(tmp))
>   break;
>   ret = put_user(tmp, (u32 __user *)data);

LGTM.

> @@ -179,7 +179,8 @@ long compat_arch_ptrace(struct task_struct *child, 
> compat_long_t request,
>   break;
>   ret = 0;
>   if (access_process_vm(child, (u64)addrOthers, ,
> - sizeof(tmp), 1) == sizeof(tmp))
> + sizeof(tmp),
> + FOLL_FORCE | FOLL_WRITE) == sizeof(tmp))
>   break;
>   ret = -EIO;
>   break;

If you're respinning this anyway, can you format that as:

if (access_process_vm(child, (u64)addrOthers, , sizeof(tmp),
  FOLL_FORCE | FOLL_WRITE) == sizeof(tmp))
break;

I realise you probably deliberately didn't do that to make the diff clearer.

Either way:

Acked-by: Michael Ellerman  (powerpc)


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

[Intel-gfx] [PATCH] i915: don't call drm_atomic_state_put on invalid pointer

[Arnd Bergmann]

The introduction of reference counting on the state structures caused
sanitize_watermarks() in i915 to break in the error handling case,
as pointed out by gcc -Wmaybe-uninitialized

drivers/gpu/drm/i915/intel_display.c: In function ‘intel_modeset_init’:
include/drm/drm_atomic.h:224:2: error: ‘state’ may be used uninitialized in 
this function [-Werror=maybe-uninitialized]

This changes the function back to only drop the reference count
when it was successfully allocated first.

Fixes: 0853695c3ba4 ("drm: Add reference counting to drm_atomic_state")
Cc: Chris Wilson 
Cc: Daniel Vetter 
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/i915/intel_display.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 6d168685bbda..6a26da143aa6 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -16314,7 +16314,7 @@ static void sanitize_watermarks(struct drm_device *dev)
 * BIOS-programmed watermarks untouched and hope for the best.
 */
WARN(true, "Could not determine valid watermarks for inherited 
state\n");
-   goto fail;
+   goto put_state;
}
 
/* Write calculated watermark values back */
@@ -16325,8 +16325,9 @@ static void sanitize_watermarks(struct drm_device *dev)
dev_priv->display.optimize_watermarks(cs);
}
 
-fail:
+put_state:
drm_atomic_state_put(state);
+fail:
drm_modeset_drop_locks();
drm_modeset_acquire_fini();
 }
-- 
2.9.0

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

Re: [Intel-gfx] [PATCH 10/10] mm: replace access_process_vm() write parameter with gup_flags

[Jesper Nilsson]

On Thu, Oct 13, 2016 at 01:20:20AM +0100, Lorenzo Stoakes wrote:
> This patch removes the write parameter from access_process_vm() and replaces 
> it
> with a gup_flags parameter as use of this function previously _implied_
> FOLL_FORCE, whereas after this patch callers explicitly pass this flag.
> 
> We make this explicit as use of FOLL_FORCE can result in surprising behaviour
> (and hence bugs) within the mm subsystem.
> 
> Signed-off-by: Lorenzo Stoakes 
> ---
>  arch/cris/arch-v32/kernel/ptrace.c |  4 ++--

For the CRIS part:

Acked-by: Jesper Nilsson 

/^JN - Jesper Nilsson
-- 
   Jesper Nilsson -- jesper.nils...@axis.com
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] Intel DRM Driver - Weathered Colours Patch

[nixuser1980]

Hello All,

Please find a proposed workaround patch for a weathered colours 
(incorrect assignment to Limited RGB setting) issue.

The weathered colour issue is documented at:

https://bugs.archlinux.org/task/46472
https://wiki.archlinux.org/index.php/Intel_graphics#Weathered_colors_.28color_range_problem.29
https://losca.blogspot.com.au/2013/11/workaround-for-setting-full-rgb-when.html


This patch, which I have shared with Jesse Barnes, provides a kernel 
command line option "i915.rgb_mode" with two usable options:


i915.rgb_mode=1 gives forced Full RGB Mode;
i915.rgb_mode=2 gives forced Limited RGB Mode.

Any other value passed to i915.rgb_mode will call the default Automatic 
RGB mode.


A limitation of this patch is that the KMS framebuffer needs to be 
interrupted, such as occurs when xorg-server starts.
i.e. if xorg-server were not to be started, the weathered colour issue 
remains in effect, even with a switch from one tty to another.
For reference, the machine that I am testing on is a 4770k (Haswell, 
Core i7).
I am investigating the issue further to improve this workaround so that 
the change from KMS to xorg-server is not required for the patch to come 
into effect.


I have tested this patch on Debian Testing.


-Damien Sticklen
diff -ruN linux-4.8.1/drivers/gpu/drm/i915/i915_params.c linux-4.8.1-patched/drivers/gpu/drm/i915/i915_params.c
--- linux-4.8.1/drivers/gpu/drm/i915/i915_params.c	2016-10-07 21:03:33.0 +0800
+++ linux-4.8.1-patched/drivers/gpu/drm/i915/i915_params.c	2016-10-18 21:36:12.051442687 +0800
@@ -54,6 +54,7 @@
 	.verbose_state_checks = 1,
 	.nuclear_pageflip = 0,
 	.edp_vswing = 0,
+	.rgb_mode = 0,
 	.enable_guc_loading = 0,
 	.enable_guc_submission = 0,
 	.guc_log_level = -1,
@@ -200,6 +201,10 @@
 		 "(0=use value from vbt [default], 1=low power swing(200mV),"
 		 "2=default swing(400mV))");
 
+/* Override for the RGB Mode Auto detection that was introduced in Linux 3.8.  This will provide the user with FULL, and LIMITED on the kernel commandline */
+module_param_named(rgb_mode, i915.rgb_mode, int, 0400);
+MODULE_PARM_DESC(rgb_mode, "Override RGB Mode (1=Full RGB MODE, 2=Limited RGB Mode; Default: 0 (Automatic RGB Mode - Lets the driver select))");
+
 module_param_named_unsafe(enable_guc_loading, i915.enable_guc_loading, int, 0400);
 MODULE_PARM_DESC(enable_guc_loading,
 		"Enable GuC firmware loading "
diff -ruN linux-4.8.1/drivers/gpu/drm/i915/i915_params.h linux-4.8.1-patched/drivers/gpu/drm/i915/i915_params.h
--- linux-4.8.1/drivers/gpu/drm/i915/i915_params.h	2016-10-07 21:03:33.0 +0800
+++ linux-4.8.1-patched/drivers/gpu/drm/i915/i915_params.h	2016-10-18 21:36:12.059442587 +0800
@@ -51,6 +51,7 @@
 	int use_mmio_flip;
 	int mmio_debug;
 	int edp_vswing;
+	int rgb_mode; /* Do not allow the kernel to select the output color width */
 	unsigned int inject_load_failure;
 	/* leave bools at the end to not create holes */
 	bool enable_hangcheck;
diff -ruN linux-4.8.1/drivers/gpu/drm/i915/intel_hdmi.c linux-4.8.1-patched/drivers/gpu/drm/i915/intel_hdmi.c
--- linux-4.8.1/drivers/gpu/drm/i915/intel_hdmi.c	2016-10-07 21:03:33.0 +0800
+++ linux-4.8.1-patched/drivers/gpu/drm/i915/intel_hdmi.c	2016-10-18 21:36:12.059442587 +0800
@@ -1585,7 +1585,22 @@
 		goto done;
 	}
 
+	/* Implement the RGB Override specified on the kernel command line*/
 	if (property == dev_priv->broadcast_rgb_property) {
+		if (i915.rgb_mode == 1) {
+			intel_hdmi->color_range_auto = false;
+			intel_hdmi->limited_color_range = false;
+
+			goto done;
+		}
+		else if (i915.rgb_mode == 2) {
+			intel_hdmi->color_range_auto = false;
+			intel_hdmi->limited_color_range = true;
+
+			goto done;
+		}
+	
+		/* If an override option is not provided in the kernel commandline, let the driver select the mode */
 		bool old_auto = intel_hdmi->color_range_auto;
 		bool old_range = intel_hdmi->limited_color_range;
 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 06/10] mm: replace get_user_pages() write/force parameters with gup_flags

[Jesper Nilsson]

On Thu, Oct 13, 2016 at 01:20:16AM +0100, Lorenzo Stoakes wrote:
> This patch removes the write and force parameters from get_user_pages() and
> replaces them with a gup_flags parameter to make the use of FOLL_FORCE 
> explicit
> in callers as use of this flag can result in surprising behaviour (and hence
> bugs) within the mm subsystem.
> 
> Signed-off-by: Lorenzo Stoakes 
> ---
>  arch/cris/arch-v32/drivers/cryptocop.c |  4 +---

For the CRIS part:

Acked-by: Jesper Nilsson 

/^JN - Jesper Nilsson
-- 
   Jesper Nilsson -- jesper.nils...@axis.com
___
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/gvt: clean up intel_gvt.h as interface for i915 core (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/gvt: clean up intel_gvt.h as interface for i915 core (rev3)
URL   : https://patchwork.freedesktop.org/series/14078/
State : failure

== Summary ==

Series 14078v3 drm/i915/gvt: clean up intel_gvt.h as interface for i915 core
https://patchwork.freedesktop.org/api/1.0/series/14078/revisions/3/mbox/

Test drv_module_reload_basic:
dmesg-warn -> PASS   (fi-skl-6700hq)
Test gem_exec_suspend:
Subgroup basic-s3:
pass   -> DMESG-WARN (fi-skl-6700hq)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-skl-6700hq)
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-skl-6700hq)
pass   -> INCOMPLETE (fi-snb-2600)
Subgroup suspend-read-crc-pipe-c:
pass   -> DMESG-WARN (fi-skl-6700hq)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
fi-byt-n2820 total:246  pass:211  dwarn:0   dfail:0   fail:0   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-ilk-650   total:246  pass:185  dwarn:0   dfail:0   fail:1   skip:60 
fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:219  dwarn:4   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:209  pass:176  dwarn:0   dfail:0   fail:0   skip:32 

Results at /archive/results/CI_IGT_test/Patchwork_2773/

0b12b48da3bc580102665ee9efd7e834f6def00f drm-intel-nightly: 
2016y-10m-20d-07h-52m-31s UTC integration manifest
f589a37 drm/i915/gvt: clean up intel_gvt.h as interface for i915 core

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

Re: [Intel-gfx] i915 and GTV-g maintenance, workflows and CI

[Zhenyu Wang]

On 2016.10.20 11:01:02 +0100, Chris Wilson wrote:
> On Thu, Oct 20, 2016 at 05:42:37PM +0800, Zhenyu Wang wrote:
> > On 2016.10.20 11:24:21 +0200, Daniel Vetter wrote:
> > > On Thu, Oct 20, 2016 at 12:02:54PM +0300, Jani Nikula wrote:
> > > > 
> > > > We need to formalize the process between i915 proper and GVT-g a bit
> > > > more, and address some of the current shortcomings and issues in the
> > > > process and GVT-g CI.
> > > > 
> > > > This started off internally as a random list of items, I'm including
> > > > some of the current status as well. Please comment, as some of the stuff
> > > > here are just my opinions.
> > > > 
> > > > * How do we ensure GVT-g patches get the same kind of pre-merge CI
> > > >   coverage as we have for other i915 code? Could we at least make CI run
> > > >   tests on GVT-g pull requests before merging to drm-intel trees?
> > > > 
> > > >   => Work in progress to set up GVT-g CI.
> > > 
> > > Personally I don't think gvt needs to pass drm-intel CI. If GVT folks want
> > > to do that then it's fine, but otherwise I'm leaning towards treating gvt
> > > like a sub-driver, with its own flavour of testing and review standards.
> > >
> > 
> > Normally GVT-g shouldn't impact drm-intel CI. I do like to setup GVT-g 
> > specific
> > CI with fancy multiple VMs auto test available. But it might need some time
> > for QA team to setup that way.
> 
> The problem is that gvt is a consumer of our APIs. When I change those I
> need reassurance that gvt does not break. We also need reassurance that
> when we backmerge from upstream changes to the hva do not break gvt.

yeah, I think that's also a requirement for GVT-g CI. Another side is
similiar nightly branch for gvt will be created to grab drm-intel,
gvt, vfio, kvm and future xen trees to do regression testing and with
more full testings. I hope some part of GVT-g CI could also be put in
drm-intel CI and other part is for GVT-g testing itself e.g VM
related features, etc.

-- 
Open Source Technology Center, Intel ltd.

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


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

Re: [Intel-gfx] [PATCH] drm/i915: Stop reporting error details in dmesg as well as the error-state

[Mika Kuoppala]

Chris Wilson  writes:

> As we already capture all the information from the registers into the
> error-state, also dumping that to dmesg just generates noise that upsets
> CI and users alike (and doesn't provide us with any more information).
>
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/i915_irq.c | 86 
> ++---
>  1 file changed, 11 insertions(+), 75 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 4c40a13d26e4..1d4bc67d27d4 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2578,90 +2578,26 @@ i915_err_print_instdone(struct drm_i915_private 
> *dev_priv,
>  slice, subslice, instdone->row[slice][subslice]);
>  }
>  
> -static void i915_report_and_clear_eir(struct drm_i915_private *dev_priv)
> +static void i915_clear_error_registers(struct drm_i915_private *dev_priv)
>  {
> - struct intel_instdone instdone;
> - u32 eir = I915_READ(EIR);
> - int pipe;
> -
> - if (!eir)
> - return;
> -
> - pr_err("render error detected, EIR: 0x%08x\n", eir);
> -
> - intel_engine_get_instdone(dev_priv->engine[RCS], );
> -
> - if (IS_G4X(dev_priv)) {
> - if (eir & (GM45_ERROR_MEM_PRIV | GM45_ERROR_CP_PRIV)) {
> - u32 ipeir = I915_READ(IPEIR_I965);
> -
> - pr_err("  IPEIR: 0x%08x\n", I915_READ(IPEIR_I965));
> - pr_err("  IPEHR: 0x%08x\n", I915_READ(IPEHR_I965));
> - i915_err_print_instdone(dev_priv, );
> - pr_err("  INSTPS: 0x%08x\n", I915_READ(INSTPS));
> - pr_err("  ACTHD: 0x%08x\n",
> I915_READ(ACTHD_I965));

But these are what we lose. They are not in the error state.

-Mika


> - I915_WRITE(IPEIR_I965, ipeir);
> - POSTING_READ(IPEIR_I965);
> - }
> - if (eir & GM45_ERROR_PAGE_TABLE) {
> - u32 pgtbl_err = I915_READ(PGTBL_ER);
> - pr_err("page table error\n");
> - pr_err("  PGTBL_ER: 0x%08x\n", pgtbl_err);
> - I915_WRITE(PGTBL_ER, pgtbl_err);
> - POSTING_READ(PGTBL_ER);
> - }
> - }
> + u32 eir;
>  
> - if (!IS_GEN2(dev_priv)) {
> - if (eir & I915_ERROR_PAGE_TABLE) {
> - u32 pgtbl_err = I915_READ(PGTBL_ER);
> - pr_err("page table error\n");
> - pr_err("  PGTBL_ER: 0x%08x\n", pgtbl_err);
> - I915_WRITE(PGTBL_ER, pgtbl_err);
> - POSTING_READ(PGTBL_ER);
> - }
> - }
> + if (!IS_GEN2(dev_priv))
> + I915_WRITE(PGTBL_ER, I915_READ(PGTBL_ER));
>  
> - if (eir & I915_ERROR_MEMORY_REFRESH) {
> - pr_err("memory refresh error:\n");
> - for_each_pipe(dev_priv, pipe)
> - pr_err("pipe %c stat: 0x%08x\n",
> -pipe_name(pipe), I915_READ(PIPESTAT(pipe)));
> - /* pipestat has already been acked */
> - }
> - if (eir & I915_ERROR_INSTRUCTION) {
> - pr_err("instruction error\n");
> - pr_err("  INSTPM: 0x%08x\n", I915_READ(INSTPM));
> - i915_err_print_instdone(dev_priv, );
> - if (INTEL_GEN(dev_priv) < 4) {
> - u32 ipeir = I915_READ(IPEIR);
> -
> - pr_err("  IPEIR: 0x%08x\n", I915_READ(IPEIR));
> - pr_err("  IPEHR: 0x%08x\n", I915_READ(IPEHR));
> - pr_err("  ACTHD: 0x%08x\n", I915_READ(ACTHD));
> - I915_WRITE(IPEIR, ipeir);
> - POSTING_READ(IPEIR);
> - } else {
> - u32 ipeir = I915_READ(IPEIR_I965);
> -
> - pr_err("  IPEIR: 0x%08x\n", I915_READ(IPEIR_I965));
> - pr_err("  IPEHR: 0x%08x\n", I915_READ(IPEHR_I965));
> - pr_err("  INSTPS: 0x%08x\n", I915_READ(INSTPS));
> - pr_err("  ACTHD: 0x%08x\n", I915_READ(ACTHD_I965));
> - I915_WRITE(IPEIR_I965, ipeir);
> - POSTING_READ(IPEIR_I965);
> - }
> - }
> + if (INTEL_GEN(dev_priv) < 4)
> + I915_WRITE(IPEIR, I915_READ(IPEIR));
> + else
> + I915_WRITE(IPEIR_I965, I915_READ(IPEIR_I965));
>  
> - I915_WRITE(EIR, eir);
> - POSTING_READ(EIR);
> + I915_WRITE(EIR, I915_READ(EIR));
>   eir = I915_READ(EIR);
>   if (eir) {
>   /*
>* some errors might have become stuck,
>* mask them.
>*/
> - DRM_ERROR("EIR stuck: 0x%08x, masking\n", eir);
> + DRM_DEBUG_DRIVER("EIR stuck: 0x%08x, masking\n", eir);
>   I915_WRITE(EMR, I915_READ(EMR) | 

Re: [Intel-gfx] [PATCH] drm/i915: Stop reporting error details in dmesg as well as the error-state

[Chris Wilson]

On Thu, Oct 20, 2016 at 01:47:28PM +0300, Mika Kuoppala wrote:
> Chris Wilson  writes:
> 
> > As we already capture all the information from the registers into the
> > error-state, also dumping that to dmesg just generates noise that upsets
> > CI and users alike (and doesn't provide us with any more information).
> >
> > Signed-off-by: Chris Wilson 
> > ---
> >  drivers/gpu/drm/i915/i915_irq.c | 86 
> > ++---
> >  1 file changed, 11 insertions(+), 75 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c 
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index 4c40a13d26e4..1d4bc67d27d4 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -2578,90 +2578,26 @@ i915_err_print_instdone(struct drm_i915_private 
> > *dev_priv,
> >slice, subslice, instdone->row[slice][subslice]);
> >  }
> >  
> > -static void i915_report_and_clear_eir(struct drm_i915_private *dev_priv)
> > +static void i915_clear_error_registers(struct drm_i915_private *dev_priv)
> >  {
> > -   struct intel_instdone instdone;
> > -   u32 eir = I915_READ(EIR);
> > -   int pipe;
> > -
> > -   if (!eir)
> > -   return;
> > -
> > -   pr_err("render error detected, EIR: 0x%08x\n", eir);
> > -
> > -   intel_engine_get_instdone(dev_priv->engine[RCS], );
> > -
> > -   if (IS_G4X(dev_priv)) {
> > -   if (eir & (GM45_ERROR_MEM_PRIV | GM45_ERROR_CP_PRIV)) {
> > -   u32 ipeir = I915_READ(IPEIR_I965);
> > -
> > -   pr_err("  IPEIR: 0x%08x\n", I915_READ(IPEIR_I965));
> > -   pr_err("  IPEHR: 0x%08x\n", I915_READ(IPEHR_I965));
> > -   i915_err_print_instdone(dev_priv, );
> > -   pr_err("  INSTPS: 0x%08x\n", I915_READ(INSTPS));
> > -   pr_err("  ACTHD: 0x%08x\n",
> > I915_READ(ACTHD_I965));
> 
> But these are what we lose. They are not in the error state.

EIR, IPEIR, IPEHR, INSTPS, and ACTHD (note these are per-ring) are all in
the error state. What am I missing?
-Chris

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

Re: [Intel-gfx] i915 and GTV-g maintenance, workflows and CI

[Jani Nikula]

On Thu, 20 Oct 2016, Zhenyu Wang  wrote:
> On 2016.10.20 11:24:21 +0200, Daniel Vetter wrote:
>> On Thu, Oct 20, 2016 at 12:02:54PM +0300, Jani Nikula wrote:
>> > * GVT-g bug management. Do you have something set up already? Would be
>> >   great to be able to use https://bugs.freedesktop.org so we could
>> >   reassign between i915 and GVT-g.
>> 
>> +1.
>
> yeah, that's also in our plan, will create new category for GVT-g driver.
> Our QA team will handle that.

Please connect them with Martin Peres (CC'd) who'll be able to get this
done.

BR,
Jani.

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

[Intel-gfx] [PATCH] drm/i915/gvt: Implement WaForceWakeRenderDuringMmioTLBInvalidate

[Arkadiusz Hiler]

When invalidating RCS TLB the device can enter RC6 state interrupting
the process, therefore the need for render forcewake for the whole
procedure.

This WA is needed for all production SKL SKUs.

References: HSD#2136899, HSD#1404391274
Cc: Mika Kuoppala 
Cc: Zhenyu Wang 
Signed-off-by: Arkadiusz Hiler 
---
 drivers/gpu/drm/i915/gvt/render.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/i915/gvt/render.c 
b/drivers/gpu/drm/i915/gvt/render.c
index f54ab85..f5000ea 100644
--- a/drivers/gpu/drm/i915/gvt/render.c
+++ b/drivers/gpu/drm/i915/gvt/render.c
@@ -134,11 +134,22 @@ static void handle_tlb_pending_event(struct intel_vgpu 
*vgpu, int ring_id)
 
reg = _MMIO(regs[ring_id]);
 
+   /* WaForceWakeRenderDuringMmioTLBInvalidate:skl
+* we need to put a forcewake when invalidating RCS TLB caches,
+* otherwise device can go to RC6 state and interrupt invalidation
+* process */
+   if (IS_SKYLAKE(dev_priv) && ring_id == RCS)
+   intel_uncore_forcewake_get(dev_priv, FORCEWAKE_RENDER);
+
I915_WRITE(reg, 0x1);
 
if (wait_for_atomic((I915_READ(reg) == 0), 50))
gvt_err("timeout in invalidate ring (%d) tlb\n", ring_id);
 
+   if (IS_SKYLAKE(dev_priv) && ring_id == RCS)
+   intel_uncore_forcewake_put(dev_priv, FORCEWAKE_RENDER);
+
+
gvt_dbg_core("invalidate TLB for ring %d\n", ring_id);
 }
 
-- 
2.7.4

___
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 drm/i915/gvt: Implement WaForceWakeRenderDuringMmioTLBInvalidate

[Ville Syrjälä]

On Thu, Oct 20, 2016 at 01:52:32PM +0200, Arkadiusz Hiler wrote:
> On Thu, Oct 20, 2016 at 11:17:09AM +, Patchwork wrote:
> > == Series Details ==
> > 
> > Series: drm/i915/gvt: Implement WaForceWakeRenderDuringMmioTLBInvalidate
> > URL   : https://patchwork.freedesktop.org/series/14097/
> > State : warning
> > 
> > == Summary ==
> > 
> > Series 14097v1 drm/i915/gvt: Implement 
> > WaForceWakeRenderDuringMmioTLBInvalidate
> > https://patchwork.freedesktop.org/api/1.0/series/14097/revisions/1/mbox/
> > 
> > Test drv_module_reload_basic:
> > dmesg-warn -> PASS   (fi-skl-6700hq)
> > Test gem_exec_suspend:
> > Subgroup basic-s3:
> > pass   -> DMESG-WARN (fi-skl-6700hq)
> > Test kms_pipe_crc_basic:
> > Subgroup suspend-read-crc-pipe-a:
> > pass   -> DMESG-WARN (fi-skl-6700hq)
> > Subgroup suspend-read-crc-pipe-b:
> > pass   -> DMESG-WARN (fi-skl-6700hq)
> > Subgroup suspend-read-crc-pipe-c:
> > pass   -> DMESG-WARN (fi-skl-6700hq)
> 
> Seems to not be related to the change made.

Please quote a bit of the error message(s) so that others might judge
that well, without having to open up the results themselves.

-- 
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] i915 and GTV-g maintenance, workflows and CI

[Chris Wilson]

On Thu, Oct 20, 2016 at 05:42:37PM +0800, Zhenyu Wang wrote:
> On 2016.10.20 11:24:21 +0200, Daniel Vetter wrote:
> > On Thu, Oct 20, 2016 at 12:02:54PM +0300, Jani Nikula wrote:
> > > 
> > > We need to formalize the process between i915 proper and GVT-g a bit
> > > more, and address some of the current shortcomings and issues in the
> > > process and GVT-g CI.
> > > 
> > > This started off internally as a random list of items, I'm including
> > > some of the current status as well. Please comment, as some of the stuff
> > > here are just my opinions.
> > > 
> > > * How do we ensure GVT-g patches get the same kind of pre-merge CI
> > >   coverage as we have for other i915 code? Could we at least make CI run
> > >   tests on GVT-g pull requests before merging to drm-intel trees?
> > > 
> > >   => Work in progress to set up GVT-g CI.
> > 
> > Personally I don't think gvt needs to pass drm-intel CI. If GVT folks want
> > to do that then it's fine, but otherwise I'm leaning towards treating gvt
> > like a sub-driver, with its own flavour of testing and review standards.
> >
> 
> Normally GVT-g shouldn't impact drm-intel CI. I do like to setup GVT-g 
> specific
> CI with fancy multiple VMs auto test available. But it might need some time
> for QA team to setup that way.

The problem is that gvt is a consumer of our APIs. When I change those I
need reassurance that gvt does not break. We also need reassurance that
when we backmerge from upstream changes to the hva do not break gvt.
-Chris

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

Re: [Intel-gfx] [PATCH] drm: Complete CEA modedb(VIC 1-107)

[Sharma, Shashank]

Adding Jose and Daniel in cc. 

Regards
Shashank 
-Original Message-
From: Sharma, Shashank 
Sent: Thursday, October 20, 2016 3:58 PM
To: dri-de...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org
Cc: airl...@redhat.com; =daniel.vet...@intel.com; jose.ab...@synopsys.com; 
Sharma, Shashank ; Joes Abreu 

Subject: [PATCH] drm: Complete CEA modedb(VIC 1-107)

CEA-861-F specs defines new 4k video modes to be used with HDMI 2.0 EDIDs. 
These modes start at VIC=93 and go all the way till VIC=107.

Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now to be 
able to parse 4k modes using the existing techniques, we have to complete the 
modedb (VIC=65 onwards).

This patch adds:
- Timings for existing CEA video modes (from VIC=65 till VIC=92)
- Newly added 4k modes (from VIC=93 to VIC=107).

Signed-off-by: Shashank Sharma 
Signed-off-by: Sonika Jindal 

Cc: Joes Abreu 
---
 drivers/gpu/drm/drm_edid.c | 231 +
 1 file changed, 231 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 
95de47b..0b97a1b 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -994,6 +994,237 @@ struct minimode {
   2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
 .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+   /* 65 - 1280x720@24Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280, 3040,
+  3080, 3300, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 66 - 1280x720@25Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
+  3740, 3960, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 67 - 1280x720@30Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3040,
+  3080, 3300, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 68 - 1280x720@50Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1720,
+  1760, 1980, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 69 - 1280x720@60Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1390,
+  1430, 1650, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 70 - 1280x720@100Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1720,
+  1760, 1980, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 71 - 1280x720@120Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1390,
+  1430, 1650, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 120, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 72 - 1920x1080@24Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2558,
+  2602, 2750, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 73 - 1920x1080@25Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2448,
+  2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 74 - 1920x1080@30Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2008,
+  2052, 2200, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 75 - 1920x1080@50Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 148500, 1920, 2448,
+  2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 76 - 

[Intel-gfx] [PATCH dim] dim-update-next: Update DRIVER_TIMESTAMP

[Chris Wilson]

Along with the DRIVER_DATE, also update the DRIVER_TIMESTAMP as measured
in seconds from the start of the epoch.

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
---
 dim | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/dim b/dim
index 5fb3a0f..6670593 100755
--- a/dim
+++ b/dim
@@ -881,7 +881,8 @@ function dim_update_next
fi
 
driver_date=`date +%Y%m%d`
-   $DRY sed -i -e "s/^#define DRIVER_DATE.*\"[0-9]*\"$/#define 
DRIVER_DATE\t\t\"$driver_date\"/" \
+   driver_timestamp=`date +%s`
+   $DRY sed -i -e "s/^#define DRIVER_DATE.*\"[0-9]*\"$/#define 
DRIVER_DATE\t\t\"$driver_date\"/; s/^#define DRIVER_TIMESTAMP.*/#define 
DRIVER_TIMESTAMP\t$driver_timestamp/" \
 drivers/gpu/drm/i915/i915_drv.h
$DRY git add drivers/gpu/drm/i915/i915_drv.h
echo -e "drm/i915: Update DRIVER_DATE to $driver_date\n\nSigned-off-by: 
Daniel Vetter " | \
-- 
2.9.3

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

Re: [Intel-gfx] [PATCH RESEND 9/9] drm/i915: set proper N/M in modeset

[Jani Nikula]

On Thu, 20 Oct 2016, "Yang, Libin"  wrote:
>> >> Any particular reason these M/N values are half of what they're in
>> >> table
>> >> 2-104 of DP 1.4 spec? (Admittedly the table is an informative
>> >> example.)
>> >
>> > For HDMI, we found only set N is enough. HW then can handle the
>> remaining.
>> 
>> I meant, the M and N values in this part of the dp_aud_n_m table are 1/2 of
>> what they are in the DP spec table. Why?
>
> Which table are you meaning? I calculate the values myself. I didn't find the
> full table in DP spec. I only find the table for 270MHz and 162MHz in 
> Table 2-50: Examples of Maud and Naud Values

Table 2-104 in DP 1.4. Maybe you're looking at an older version of the
spec.

BR,
Jani.


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

Re: [Intel-gfx] [PATCH RESEND 9/9] drm/i915: set proper N/M in modeset

[Ville Syrjälä]

On Thu, Oct 20, 2016 at 02:34:34PM +0300, Jani Nikula wrote:
> On Thu, 20 Oct 2016, "Yang, Libin"  wrote:
> >> >> Any particular reason these M/N values are half of what they're in
> >> >> table
> >> >> 2-104 of DP 1.4 spec? (Admittedly the table is an informative
> >> >> example.)
> >> >
> >> > For HDMI, we found only set N is enough. HW then can handle the
> >> remaining.
> >> 
> >> I meant, the M and N values in this part of the dp_aud_n_m table are 1/2 of
> >> what they are in the DP spec table. Why?
> >
> > Which table are you meaning? I calculate the values myself. I didn't find 
> > the
> > full table in DP spec. I only find the table for 270MHz and 162MHz in 
> > Table 2-50: Examples of Maud and Naud Values
> 
> Table 2-104 in DP 1.4. Maybe you're looking at an older version of the
> spec.

So it looks like they used the same M value for all link frequencies
in that example, which for 540M ends up being double what the minimal
accurate value is. But as both M and N are doubled the ratio is still
exactly the same.

And there is indeed a 64k and 128k bitrates added as well. Those are
not classified under HBR audio. But as those can't be expressed via
short audio descriptors in the EDID, I don't think they would be
accepted by ALSA. Or am I wrong? I do wonder how they are supposed to be
used though since there must be some way for the sink to advertise
them, otherwise I can't see the point in adding them.

-- 
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 igt] igt/drv_hangman: Use manual error-state generation

[Chris Wilson]

On Thu, Oct 20, 2016 at 10:46:01AM +0100, Chris Wilson wrote:
> On Thu, Oct 20, 2016 at 11:29:05AM +0200, Daniel Vetter wrote:
> > On Thu, Oct 20, 2016 at 10:07:39AM +0100, Chris Wilson wrote:
> > > For the basic error state, we only desire that an error state be created
> > > following a hang. For that purpose, we do not need a real hang (slow
> > > 6-12s) but can inject one instead (fast <1s).
> > > 
> > > Signed-off-by: Chris Wilson 
> > 
> > Should we instead speed up hangcheck? I think there's lots of value in
> > making sure not just error dumping, but also hang detection works somewhat
> > in BAT. Since if it doesn't any attempt at a full run will lead to pretty
> > serious disasters. And I have this dream that BAT is the gating thing
> > deciding whether a patch series deserves a complete pre-merge run ;-)
> 
> We have full-hang detection in BAT elsewhere as well. This particular
> test was only asking the question "do we generate an error state", hence
> why I felt it was safe to just do that and skip a simulated hang.
>  
> > But since this is a controlled enviromnent we could make hangcheck
> > super-fast at timing out with some debugfs knob. Would probably also help
> > a lot with speeding up the gazillion of testcases in gem_reset_stats.
> 
> I have considered i915.hangcheck_interval_ms many a time. It is not just
> the interval but the hangcheck score threshold to consider. If we can
> trust our activity detection, we would be safe with a hangcheck every
> jiffie (at some overhead mind you), but we would declare a dos too soon.

Thinking of which, Mika did have some patches to move towards a time
accrued metric...
-Chris

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

[Intel-gfx] [PULL] GVT-g device model core fixes

[Zhenyu Wang]

Hi,

This is second pull request for GVT-g sub module which contains
fixes for issues within first pull request.

Regression test has been passed combining this new pull request
with unmerged driver facilities to test for VMs.

Thanks.

--
The following changes since commit 1140f9ed051011e06a2a15c73efe57ac0b0cdc8d:

  drm/i915/gvt: Fix build failure after intel_engine_cs change (2016-10-18 
08:24:49 +0200)

are available in the git repository at:

  https://github.com/01org/gvt-linux.git tags/gvt-next-fix-2016-10-20

for you to fetch changes up to 19e6393fb5366a89705a62b3276ce42e990d12ce:

  drm/i915/gvt: do not ignore return value of create_scratch_page (2016-10-20 
17:31:36 +0800)


gvt-next-fix-2016-10-20

This contains fix for first pull request.
- clean up header mess between i915 core and gvt
- new MAINTAINERS item
- new kernel-doc section
- fix compiling warnings
- gvt gem fix series from Chris
- fix for i915 intel_engine_cs change
- some sparse fixes from Changbin


Chris Wilson (10):
  drm/i915/gvt: Add runtime pm around fences
  drm/i915/gvt: i915_gem_object_create() returns an error pointer
  drm/i915/gvt: Use the returned VMA to provide the virtual address
  drm/i915/gvt: Remove dangerous unpin of backing storage of bound GPU 
object
  drm/i915/gvt: Hold a reference on the request
  drm/i915/gvt: Stop checking for impossible interrupts from a kthread
  drm/i915/gvt: Stop waiting whilst holding struct_mutex
  drm/i915/gvt: Use common mapping routines for indirect_ctx object
  drm/i915/gvt: Use common mapping routines for shadow_bb object
  drm/i915/gvt: Remove defunct vmap_batch()

Du, Changbin (4):
  drm/i915/gvt: fix sparse warnings on different address spaces
  drm/i915/gvt: mark symbols static where possible
  drm/i915/gvt: fix spare warnings on odd constant _Bool cast
  drm/i915/gvt: do not ignore return value of create_scratch_page

Zhenyu Wang (5):
  drm/i915/gvt: clean up intel_gvt.h as interface for i915 core
  MAINTAINERS: Add new Intel GVT-g driver maintainer
  drm/i915/gvt: Fix warning on obsolete function usage
  Documentation/gpu: Add section for Intel GVT-g host support
  drm/i915/gvt: properly access enabled intel_engine_cs

 Documentation/gpu/i915.rst  |   9 +++
 MAINTAINERS |  10 +++
 drivers/gpu/drm/i915/gvt/aperture_gm.c  |  11 +++
 drivers/gpu/drm/i915/gvt/cfg_space.c|   1 +
 drivers/gpu/drm/i915/gvt/cmd_parser.c   | 135 +++-
 drivers/gpu/drm/i915/gvt/display.c  |   3 +-
 drivers/gpu/drm/i915/gvt/edid.c |   1 +
 drivers/gpu/drm/i915/gvt/execlist.c |  48 +++-
 drivers/gpu/drm/i915/gvt/firmware.c |  10 ++-
 drivers/gpu/drm/i915/gvt/gtt.c  |  15 ++--
 drivers/gpu/drm/i915/gvt/gvt.c  |  19 +++--
 drivers/gpu/drm/i915/gvt/gvt.h  |   9 ++-
 drivers/gpu/drm/i915/gvt/handlers.c |  13 +--
 drivers/gpu/drm/i915/gvt/interrupt.c|   3 +-
 drivers/gpu/drm/i915/gvt/mmio.c |   1 +
 drivers/gpu/drm/i915/gvt/opregion.c |   3 +-
 drivers/gpu/drm/i915/gvt/render.c   |   1 +
 drivers/gpu/drm/i915/gvt/sched_policy.c |  15 ++--
 drivers/gpu/drm/i915/gvt/scheduler.c|  62 ---
 drivers/gpu/drm/i915/gvt/vgpu.c |   2 +
 drivers/gpu/drm/i915/i915_drv.h |   4 +-
 drivers/gpu/drm/i915/intel_gvt.c|   8 +-
 drivers/gpu/drm/i915/intel_gvt.h|   3 +-
 23 files changed, 208 insertions(+), 178 deletions(-)


-- 
Open Source Technology Center, Intel ltd.

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


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

[Intel-gfx] [PATCH] drm: Complete CEA modedb(VIC 1-107)

[Shashank Sharma]

CEA-861-F specs defines new 4k video modes to be used with
HDMI 2.0 EDIDs. These modes start at VIC=93 and go all the
way till VIC=107.

Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
to be able to parse 4k modes using the existing techniques, we have
to complete the modedb (VIC=65 onwards).

This patch adds:
- Timings for existing CEA video modes (from VIC=65 till VIC=92)
- Newly added 4k modes (from VIC=93 to VIC=107).

Signed-off-by: Shashank Sharma 
Signed-off-by: Sonika Jindal 

Cc: Joes Abreu 
---
 drivers/gpu/drm/drm_edid.c | 231 +
 1 file changed, 231 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 95de47b..0b97a1b 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -994,6 +994,237 @@ struct minimode {
   2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
 .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+   /* 65 - 1280x720@24Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280, 3040,
+  3080, 3300, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 66 - 1280x720@25Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
+  3740, 3960, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 67 - 1280x720@30Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3040,
+  3080, 3300, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 68 - 1280x720@50Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1720,
+  1760, 1980, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 69 - 1280x720@60Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1390,
+  1430, 1650, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 70 - 1280x720@100Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1720,
+  1760, 1980, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 71 - 1280x720@120Hz */
+   { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1390,
+  1430, 1650, 0, 720, 725, 730, 750, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 120, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 72 - 1920x1080@24Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2558,
+  2602, 2750, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 73 - 1920x1080@25Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2448,
+  2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 74 - 1920x1080@30Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2008,
+  2052, 2200, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 75 - 1920x1080@50Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 148500, 1920, 2448,
+  2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 76 - 1920x1080@60Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 148500, 1920, 2008,
+  2052, 2200, 0, 1080, 1084, 1089, 1125, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+   /* 77 - 1920x1080@100Hz */
+   { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 297000, 1920, 2448,
+  2492, 2640, 

Re: [Intel-gfx] [PATCH 06/41] drm/i915: Support asynchronous waits on struct fence from i915_gem_request

[Chris Wilson]

On Mon, Oct 17, 2016 at 03:20:14PM +0300, Joonas Lahtinen wrote:
> On pe, 2016-10-14 at 13:17 +0100, Chris Wilson wrote:
> > We will need to wait on DMA completion (as signaled via struct fence)
> > before executing our i915_gem_request. Therefore we want to expose a
> > method for adding the await on the fence itself to the request.
> > 
> > v2: Add a comment detailing a failure to handle a signal-on-any
> > fence-array.
> > 
> > Signed-off-by: Chris Wilson 
> 
> With the magic removed (10*HZ), this was already;

You'll note I haven't repainted the magic because the magic is being
cargo-culted...
-Chris

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

Re: [Intel-gfx] [PATCH] drm/i915: Stop reporting error details in dmesg as well as the error-state

[Mika Kuoppala]

Chris Wilson  writes:

> On Thu, Oct 20, 2016 at 01:47:28PM +0300, Mika Kuoppala wrote:
>> Chris Wilson  writes:
>> 
>> > As we already capture all the information from the registers into the
>> > error-state, also dumping that to dmesg just generates noise that upsets
>> > CI and users alike (and doesn't provide us with any more information).
>> >
>> > Signed-off-by: Chris Wilson 
>> > ---
>> >  drivers/gpu/drm/i915/i915_irq.c | 86 
>> > ++---
>> >  1 file changed, 11 insertions(+), 75 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/i915_irq.c 
>> > b/drivers/gpu/drm/i915/i915_irq.c
>> > index 4c40a13d26e4..1d4bc67d27d4 100644
>> > --- a/drivers/gpu/drm/i915/i915_irq.c
>> > +++ b/drivers/gpu/drm/i915/i915_irq.c
>> > @@ -2578,90 +2578,26 @@ i915_err_print_instdone(struct drm_i915_private 
>> > *dev_priv,
>> >   slice, subslice, instdone->row[slice][subslice]);
>> >  }
>> >  
>> > -static void i915_report_and_clear_eir(struct drm_i915_private *dev_priv)
>> > +static void i915_clear_error_registers(struct drm_i915_private *dev_priv)
>> >  {
>> > -  struct intel_instdone instdone;
>> > -  u32 eir = I915_READ(EIR);
>> > -  int pipe;
>> > -
>> > -  if (!eir)
>> > -  return;
>> > -
>> > -  pr_err("render error detected, EIR: 0x%08x\n", eir);
>> > -
>> > -  intel_engine_get_instdone(dev_priv->engine[RCS], );
>> > -
>> > -  if (IS_G4X(dev_priv)) {
>> > -  if (eir & (GM45_ERROR_MEM_PRIV | GM45_ERROR_CP_PRIV)) {
>> > -  u32 ipeir = I915_READ(IPEIR_I965);
>> > -
>> > -  pr_err("  IPEIR: 0x%08x\n", I915_READ(IPEIR_I965));
>> > -  pr_err("  IPEHR: 0x%08x\n", I915_READ(IPEHR_I965));
>> > -  i915_err_print_instdone(dev_priv, );
>> > -  pr_err("  INSTPS: 0x%08x\n", I915_READ(INSTPS));
>> > -  pr_err("  ACTHD: 0x%08x\n",
>> > I915_READ(ACTHD_I965));
>> 
>> But these are what we lose. They are not in the error state.
>
> EIR, IPEIR, IPEHR, INSTPS, and ACTHD (note these are per-ring) are all in
> the error state. What am I missing?

Grep picked up stuff from i810_regs.h and I was fooled. My bad.

Indeed they are already in the error state so the commit message
is correct about the information we already have.

Reviewed-by: Mika Kuoppala 

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

[Intel-gfx] [bug report] drm/i915/gvt: vGPU command scanner

[Dan Carpenter]

Hello Zhi Wang,

The patch be1da7070aea: "drm/i915/gvt: vGPU command scanner" from May
3, 2016, leads to the following static checker warning:

drivers/gpu/drm/i915/gvt/cmd_parser.c:1420 cmd_handler_mi_op_2f()
warn: shift has higher precedence than mask

drivers/gpu/drm/i915/gvt/cmd_parser.c
  1417  static int cmd_handler_mi_op_2f(struct parser_exec_state *s)
  1418  {
  1419  int gmadr_bytes = s->vgpu->gvt->device_info.gmadr_bytes_in_cmd;
  1420  int op_size = ((1 << (cmd_val(s, 0) & GENMASK(20, 19) >> 19)) *
  1421  sizeof(u32));

The size calculation is wrong but I've got no idea what the fix is.

  1422  unsigned long gma, gma_high;
  1423  int ret = 0;
  1424  
  1425  if (!(cmd_val(s, 0) & (1 << 22)))
  1426  return ret;
  1427  
  1428  gma = cmd_val(s, 1) & GENMASK(31, 2);
  1429  if (gmadr_bytes == 8) {
  1430  gma_high = cmd_val(s, 2) & GENMASK(15, 0);
  1431  gma = (gma_high << 32) | gma;
  1432  }
  1433  ret = cmd_address_audit(s, gma, op_size, false);
  1434  return ret;
  1435  }

regards,
dan carpenter
___
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 drm/i915/gvt: Implement WaForceWakeRenderDuringMmioTLBInvalidate

[Arkadiusz Hiler]

On Thu, Oct 20, 2016 at 11:17:09AM +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915/gvt: Implement WaForceWakeRenderDuringMmioTLBInvalidate
> URL   : https://patchwork.freedesktop.org/series/14097/
> State : warning
> 
> == Summary ==
> 
> Series 14097v1 drm/i915/gvt: Implement 
> WaForceWakeRenderDuringMmioTLBInvalidate
> https://patchwork.freedesktop.org/api/1.0/series/14097/revisions/1/mbox/
> 
> Test drv_module_reload_basic:
> dmesg-warn -> PASS   (fi-skl-6700hq)
> Test gem_exec_suspend:
> Subgroup basic-s3:
> pass   -> DMESG-WARN (fi-skl-6700hq)
> Test kms_pipe_crc_basic:
> Subgroup suspend-read-crc-pipe-a:
> pass   -> DMESG-WARN (fi-skl-6700hq)
> Subgroup suspend-read-crc-pipe-b:
> pass   -> DMESG-WARN (fi-skl-6700hq)
> Subgroup suspend-read-crc-pipe-c:
> pass   -> DMESG-WARN (fi-skl-6700hq)

Seems to not be related to the change made.

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

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm: Complete CEA modedb(VIC 1-107)

[Patchwork]

== Series Details ==

Series: drm: Complete CEA modedb(VIC 1-107)
URL   : https://patchwork.freedesktop.org/series/14090/
State : warning

== Summary ==

Series 14090v1 drm: Complete CEA modedb(VIC 1-107)
https://patchwork.freedesktop.org/api/1.0/series/14090/revisions/1/mbox/

Test gem_busy:
Subgroup basic-hang-default:
pass   -> DMESG-WARN (fi-hsw-4770r)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
fi-byt-n2820 total:246  pass:211  dwarn:0   dfail:0   fail:0   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:223  dwarn:1   dfail:0   fail:0   skip:22 
fi-ilk-650   total:246  pass:185  dwarn:0   dfail:0   fail:1   skip:60 
fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_2774/

0b12b48da3bc580102665ee9efd7e834f6def00f drm-intel-nightly: 
2016y-10m-20d-07h-52m-31s UTC integration manifest
754b099 drm: Complete CEA modedb(VIC 1-107)

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

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/gvt: Implement WaForceWakeRenderDuringMmioTLBInvalidate

[Patchwork]

== Series Details ==

Series: drm/i915/gvt: Implement WaForceWakeRenderDuringMmioTLBInvalidate
URL   : https://patchwork.freedesktop.org/series/14097/
State : warning

== Summary ==

Series 14097v1 drm/i915/gvt: Implement WaForceWakeRenderDuringMmioTLBInvalidate
https://patchwork.freedesktop.org/api/1.0/series/14097/revisions/1/mbox/

Test drv_module_reload_basic:
dmesg-warn -> PASS   (fi-skl-6700hq)
Test gem_exec_suspend:
Subgroup basic-s3:
pass   -> DMESG-WARN (fi-skl-6700hq)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-skl-6700hq)
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-skl-6700hq)
Subgroup suspend-read-crc-pipe-c:
pass   -> DMESG-WARN (fi-skl-6700hq)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
fi-byt-n2820 total:246  pass:211  dwarn:0   dfail:0   fail:0   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-ilk-650   total:246  pass:185  dwarn:0   dfail:0   fail:1   skip:60 
fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:219  dwarn:4   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_2775/

0b12b48da3bc580102665ee9efd7e834f6def00f drm-intel-nightly: 
2016y-10m-20d-07h-52m-31s UTC integration manifest
d3ad1f3f drm/i915/gvt: Implement WaForceWakeRenderDuringMmioTLBInvalidate

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

Re: [Intel-gfx] [PATCH] drm/i915/gvt: clean up intel_gvt.h as interface for i915 core

[Chris Wilson]

On Thu, Oct 20, 2016 at 03:29:13PM +0800, Zhenyu Wang wrote:
> @@ -214,9 +215,15 @@ int intel_gvt_init_device(struct drm_i915_private 
> *dev_priv)
>   if (WARN_ON(!intel_gvt_host.initialized))
>   return -EINVAL;
>  
> - if (WARN_ON(gvt->initialized))
> + if (WARN_ON(dev_priv->gvt))
>   return -EEXIST;
>  
> + dev_priv->gvt = kzalloc(sizeof(struct intel_gvt), GFP_KERNEL);
> + if (!dev_priv->gvt)
> + return -ENOMEM;
> +
> + gvt = to_gvt(dev_priv);
> +
>   gvt_dbg_core("init gvt device\n");
>  
>   mutex_init(>lock);
> @@ -280,5 +287,6 @@ out_free_firmware:
>   intel_gvt_free_firmware(gvt);
>  out_clean_mmio_info:
>   intel_gvt_clean_mmio_info(gvt);
> + kfree(dev_priv->gvt);

And now dev_priv->gvt points where? What does
intel_gvt_active() think about that?

Allocate to the local gvt, and assign that to dev_priv->gvt at the end
once initialised and it has passed all the tests.

> diff --git a/drivers/gpu/drm/i915/gvt/gvt.h b/drivers/gpu/drm/i915/gvt/gvt.h
> index 1564554..fd33e6b 100644
> --- a/drivers/gpu/drm/i915/gvt/gvt.h
> +++ b/drivers/gpu/drm/i915/gvt/gvt.h
> @@ -213,6 +213,8 @@ struct intel_gvt {
>   unsigned long service_request;
>  };
>  
> +#define to_gvt(dev_priv) (struct intel_gvt *)(dev_priv->gvt)

Why so few brackets? Like to play dangerously?

> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 4d1133f..964d33d 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1778,7 +1778,7 @@ struct drm_i915_private {
>  
>   struct i915_virtual_gpu vgpu;
>  
> - struct intel_gvt gvt;
> + void *gvt;

Better to have a struct intel_gvt forward declaration than a void *.

>   struct intel_guc guc;
>  
> @@ -2992,7 +2992,7 @@ int intel_wait_for_register_fw(struct drm_i915_private 
> *dev_priv,
>  
>  static inline bool intel_gvt_active(struct drm_i915_private *dev_priv)
>  {
> - return dev_priv->gvt.initialized;
> + return (dev_priv->gvt != NULL);

(Why (so (many (brackets? Why redundant tests, why not Zoidberg?

>  }
>  
>  static inline bool intel_vgpu_active(struct drm_i915_private *dev_priv)
> diff --git a/drivers/gpu/drm/i915/intel_gvt.c 
> b/drivers/gpu/drm/i915/intel_gvt.c
> index 8e8596d..bae1a7d 100644
> --- a/drivers/gpu/drm/i915/intel_gvt.c
> +++ b/drivers/gpu/drm/i915/intel_gvt.c
> @@ -103,4 +103,5 @@ void intel_gvt_cleanup(struct drm_i915_private *dev_priv)
>   return;
>  
>   intel_gvt_clean_device(dev_priv);
> + kfree(dev_priv->gvt);

It wasn't allocated in intel_gvt.c, it shouldn't be freed here either.
-Chris

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

[Intel-gfx] [PATCH 2/5] drm/i915: Use RPM as the barrier for controlling user mmap access

[Chris Wilson]

We can remove the false coupling between RPM and struct mutex by the
observation that we can use the RPM wakeref as the barrier around user
mmap access. That is as we tear down the user's PTE atomically from
within rpm suspend and then to fault in new PTE requires the rpm
wakeref, means that no user access is possible through those PTE without
RPM being awake. Having made that observation, we can then remove the
presumption of having to take rpm outside of struct_mutex and so allow
fine grained acquisition of a wakeref around hw access rather than
having to remember to acquire the wakeref early on.

v2: Rejig placement of the new intel_runtime_pm_get() to be as tight
as possible around the GTT pread/pwrite.

Signed-off-by: Chris Wilson 
Cc: Imre Deak 
Cc: Daniel Vetter 
Cc: Ville Syrjälä 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_debugfs.c| 56 --
 drivers/gpu/drm/i915/i915_drv.c| 19 
 drivers/gpu/drm/i915/i915_gem.c| 42 +
 drivers/gpu/drm/i915/i915_gem_gtt.c| 17 ---
 drivers/gpu/drm/i915/i915_gem_tiling.c |  4 ---
 5 files changed, 69 insertions(+), 69 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 1b402eebd3d9..88c9d222a7e6 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -743,17 +743,32 @@ static int i915_interrupt_info(struct seq_file *m, void 
*data)
   I915_READ(VLV_IIR_RW));
seq_printf(m, "Display IMR:\t%08x\n",
   I915_READ(VLV_IMR));
-   for_each_pipe(dev_priv, pipe)
+   for_each_pipe(dev_priv, pipe) {
+   enum intel_display_power_domain power_domain;
+
+   power_domain = POWER_DOMAIN_PIPE(pipe);
+   if (!intel_display_power_get_if_enabled(dev_priv,
+   power_domain)) {
+   seq_printf(m, "Pipe %c power disabled\n",
+  pipe_name(pipe));
+   continue;
+   }
+
seq_printf(m, "Pipe %c stat:\t%08x\n",
   pipe_name(pipe),
   I915_READ(PIPESTAT(pipe)));
 
+   intel_display_power_put(dev_priv, power_domain);
+   }
+
+   intel_display_power_get(dev_priv, POWER_DOMAIN_INIT);
seq_printf(m, "Port hotplug:\t%08x\n",
   I915_READ(PORT_HOTPLUG_EN));
seq_printf(m, "DPFLIPSTAT:\t%08x\n",
   I915_READ(VLV_DPFLIPSTAT));
seq_printf(m, "DPINVGTT:\t%08x\n",
   I915_READ(DPINVGTT));
+   intel_display_power_put(dev_priv, POWER_DOMAIN_INIT);
 
for (i = 0; i < 4; i++) {
seq_printf(m, "GT Interrupt IMR %d:\t%08x\n",
@@ -1396,14 +1411,9 @@ static int i915_hangcheck_info(struct seq_file *m, void 
*unused)
 static int ironlake_drpc_info(struct seq_file *m)
 {
struct drm_i915_private *dev_priv = node_to_i915(m->private);
-   struct drm_device *dev = _priv->drm;
u32 rgvmodectl, rstdbyctl;
u16 crstandvid;
-   int ret;
 
-   ret = mutex_lock_interruptible(>struct_mutex);
-   if (ret)
-   return ret;
intel_runtime_pm_get(dev_priv);
 
rgvmodectl = I915_READ(MEMMODECTL);
@@ -1411,7 +1421,6 @@ static int ironlake_drpc_info(struct seq_file *m)
crstandvid = I915_READ16(CRSTANDVID);
 
intel_runtime_pm_put(dev_priv);
-   mutex_unlock(>struct_mutex);
 
seq_printf(m, "HD boost: %s\n", yesno(rgvmodectl & MEMMODE_BOOST_EN));
seq_printf(m, "Boost freq: %d\n",
@@ -1757,6 +1766,7 @@ static int i915_sr_status(struct seq_file *m, void 
*unused)
bool sr_enabled = false;
 
intel_runtime_pm_get(dev_priv);
+   intel_display_power_get(dev_priv, POWER_DOMAIN_INIT);
 
if (HAS_PCH_SPLIT(dev_priv))
sr_enabled = I915_READ(WM1_LP_ILK) & WM1_LP_SR_EN;
@@ -1770,6 +1780,7 @@ static int i915_sr_status(struct seq_file *m, void 
*unused)
else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
sr_enabled = I915_READ(FW_BLC_SELF_VLV) & FW_CSPWRDWNEN;
 
+   intel_display_power_put(dev_priv, POWER_DOMAIN_INIT);
intel_runtime_pm_put(dev_priv);
 
seq_printf(m, "self-refresh: %s\n",
@@ -2091,12 +2102,7 @@ static const char *swizzle_string(unsigned swizzle)
 static int i915_swizzle_info(struct seq_file *m, void *data)
 {
struct drm_i915_private *dev_priv = node_to_i915(m->private);
-   struct drm_device *dev = _priv->drm;
- 

[Intel-gfx] [PATCH 5/5] drm/i915: Move fence cancellation to runtime suspend

[Chris Wilson]

At the moment, we have dependency on the RPM as a barrier itself in both
i915_gem_release_all_mmaps() and i915_gem_restore_fences().
i915_gem_restore_fences() is also called along !runtime pm paths, but we
can move the markup of lost fences alongside releasing the mmaps into a
common i915_gem_runtime_suspend(). This has the advantage of locating
all the tricky barrier dependencies into one location.

Suggested-by: Daniel Vetter 
Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_drv.c   |  6 ++
 drivers/gpu/drm/i915/i915_drv.h   |  3 ++-
 drivers/gpu/drm/i915/i915_gem.c   | 25 +++--
 drivers/gpu/drm/i915/i915_gem_fence.c | 12 +---
 4 files changed, 32 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 885d33f341f3..99e4e044e958 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -2278,10 +2278,8 @@ static int vlv_resume_prepare(struct drm_i915_private 
*dev_priv,
 
vlv_check_no_gt_access(dev_priv);
 
-   if (rpm_resume) {
+   if (rpm_resume)
intel_init_clock_gating(dev);
-   i915_gem_restore_fences(dev);
-   }
 
return ret;
 }
@@ -2307,7 +2305,7 @@ static int intel_runtime_suspend(struct device *kdev)
 * We are safe here against re-faults, since the fault handler takes
 * an RPM reference.
 */
-   i915_gem_release_all_mmaps(dev_priv);
+   i915_gem_runtime_suspend(dev_priv);
 
intel_guc_suspend(dev);
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c87074b8ef61..4505ece9e302 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3129,9 +3129,10 @@ void i915_vma_destroy(struct i915_vma *vma);
 
 int i915_gem_object_unbind(struct drm_i915_gem_object *obj);
 int i915_gem_object_put_pages(struct drm_i915_gem_object *obj);
-void i915_gem_release_all_mmaps(struct drm_i915_private *dev_priv);
 void i915_gem_release_mmap(struct drm_i915_gem_object *obj);
 
+void i915_gem_runtime_suspend(struct drm_i915_private *dev_priv);
+
 int __must_check i915_gem_object_get_pages(struct drm_i915_gem_object *obj);
 
 static inline int __sg_page_count(struct scatterlist *sg)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 64a88ce4b3c6..41088c31ada6 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1952,10 +1952,10 @@ i915_gem_release_mmap(struct drm_i915_gem_object *obj)
intel_runtime_pm_put(i915);
 }
 
-void
-i915_gem_release_all_mmaps(struct drm_i915_private *dev_priv)
+void i915_gem_runtime_suspend(struct drm_i915_private *dev_priv)
 {
struct drm_i915_gem_object *obj, *on;
+   int i;
 
/*
 * Only called during RPM suspend. All users of the userfault_list
@@ -1970,6 +1970,27 @@ i915_gem_release_all_mmaps(struct drm_i915_private 
*dev_priv)
drm_vma_node_unmap(>base.vma_node,
   obj->base.dev->anon_inode->i_mapping);
}
+
+   /* The fence will be lost when the device powers down. If any were
+* in use by hardware (i.e. they are pinned), we should not be powering
+* down! All other fences will be reacquired by the user upon waking.
+*/
+   for (i = 0; i < dev_priv->num_fence_regs; i++) {
+   struct drm_i915_fence_reg *reg = _priv->fence_regs[i];
+   struct i915_vma *vma;
+
+   if (WARN_ON(reg->pin_count))
+   continue;
+
+   vma = fetch_and_zero(>vma);
+   if (!vma)
+   continue;
+
+   GEM_BUG_ON(!list_empty(>obj->userfault_link));
+
+   list_move(>link, _priv->mm.fence_list);
+   vma->fence = NULL;
+   }
 }
 
 /**
diff --git a/drivers/gpu/drm/i915/i915_gem_fence.c 
b/drivers/gpu/drm/i915/i915_gem_fence.c
index 67013179b8ed..3c5a8082cac3 100644
--- a/drivers/gpu/drm/i915/i915_gem_fence.c
+++ b/drivers/gpu/drm/i915/i915_gem_fence.c
@@ -343,6 +343,9 @@ i915_vma_get_fence(struct i915_vma *vma)
struct drm_i915_fence_reg *fence;
struct i915_vma *set = i915_gem_object_is_tiled(vma->obj) ? vma : NULL;
 
+   /* Note that we revoke fences on runtime suspend. Therefore the user
+* must keep the device awake whilst using the fence.
+*/
assert_rpm_wakelock_held(to_i915(vma->vm->dev));
 
/* Just update our place in the LRU if our fence is getting reused. */
@@ -368,19 +371,14 @@ i915_vma_get_fence(struct i915_vma *vma)
  * @dev: DRM device
  *
  * Restore the hw fence state to match the software tracking again, to be 
called
- * after a gpu reset and on resume.
+ * after a gpu reset and on resume. Note that on runtime suspend we only cancel
+ * the fences, 

[Intel-gfx] [PATCH v2] drm/i915/gvt: clean up intel_gvt.h as interface for i915 core

[Zhenyu Wang]

i915 core should only call functions and structures exposed through
intel_gvt.h. Remove internal gvt.h and i915_pvinfo.h.

Change for internal intel_gvt structure as private handler which
not requires to expose gvt internal structure for i915 core.

v2: Fix per Chris's comment
- carefully handle dev_priv->gvt assignment
- add necessary bracket for macro helper
- forward declartion struct intel_gvt
- keep free operation within same file handling alloc

Signed-off-by: Zhenyu Wang 
---
 drivers/gpu/drm/i915/gvt/aperture_gm.c  |  1 +
 drivers/gpu/drm/i915/gvt/cfg_space.c|  1 +
 drivers/gpu/drm/i915/gvt/cmd_parser.c   |  2 ++
 drivers/gpu/drm/i915/gvt/display.c  |  1 +
 drivers/gpu/drm/i915/gvt/edid.c |  1 +
 drivers/gpu/drm/i915/gvt/execlist.c |  1 +
 drivers/gpu/drm/i915/gvt/firmware.c |  2 ++
 drivers/gpu/drm/i915/gvt/gtt.c  |  2 ++
 drivers/gpu/drm/i915/gvt/gvt.c  | 15 ---
 drivers/gpu/drm/i915/gvt/gvt.h  |  2 ++
 drivers/gpu/drm/i915/gvt/handlers.c |  2 ++
 drivers/gpu/drm/i915/gvt/interrupt.c|  1 +
 drivers/gpu/drm/i915/gvt/mmio.c |  1 +
 drivers/gpu/drm/i915/gvt/opregion.c |  1 +
 drivers/gpu/drm/i915/gvt/render.c   |  1 +
 drivers/gpu/drm/i915/gvt/sched_policy.c |  1 +
 drivers/gpu/drm/i915/gvt/scheduler.c|  5 +++--
 drivers/gpu/drm/i915/gvt/vgpu.c |  2 ++
 drivers/gpu/drm/i915/i915_drv.h |  4 ++--
 drivers/gpu/drm/i915/intel_gvt.h|  3 +--
 20 files changed, 40 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/aperture_gm.c 
b/drivers/gpu/drm/i915/gvt/aperture_gm.c
index e0211f8..db503c1 100644
--- a/drivers/gpu/drm/i915/gvt/aperture_gm.c
+++ b/drivers/gpu/drm/i915/gvt/aperture_gm.c
@@ -35,6 +35,7 @@
  */
 
 #include "i915_drv.h"
+#include "gvt.h"
 
 #define MB_TO_BYTES(mb) ((mb) << 20ULL)
 #define BYTES_TO_MB(b) ((b) >> 20ULL)
diff --git a/drivers/gpu/drm/i915/gvt/cfg_space.c 
b/drivers/gpu/drm/i915/gvt/cfg_space.c
index 16360e4..4c68774 100644
--- a/drivers/gpu/drm/i915/gvt/cfg_space.c
+++ b/drivers/gpu/drm/i915/gvt/cfg_space.c
@@ -32,6 +32,7 @@
  */
 
 #include "i915_drv.h"
+#include "gvt.h"
 
 enum {
INTEL_GVT_PCI_BAR_GTTMMIO = 0,
diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.c 
b/drivers/gpu/drm/i915/gvt/cmd_parser.c
index 5808ee7..5b4658f 100644
--- a/drivers/gpu/drm/i915/gvt/cmd_parser.c
+++ b/drivers/gpu/drm/i915/gvt/cmd_parser.c
@@ -36,6 +36,8 @@
 
 #include 
 #include "i915_drv.h"
+#include "gvt.h"
+#include "i915_pvinfo.h"
 #include "trace.h"
 
 #define INVALID_OP(~0U)
diff --git a/drivers/gpu/drm/i915/gvt/display.c 
b/drivers/gpu/drm/i915/gvt/display.c
index 534000b..d8908d4 100644
--- a/drivers/gpu/drm/i915/gvt/display.c
+++ b/drivers/gpu/drm/i915/gvt/display.c
@@ -33,6 +33,7 @@
  */
 
 #include "i915_drv.h"
+#include "gvt.h"
 
 static int get_edp_pipe(struct intel_vgpu *vgpu)
 {
diff --git a/drivers/gpu/drm/i915/gvt/edid.c b/drivers/gpu/drm/i915/gvt/edid.c
index a07e427..7e1da1c 100644
--- a/drivers/gpu/drm/i915/gvt/edid.c
+++ b/drivers/gpu/drm/i915/gvt/edid.c
@@ -33,6 +33,7 @@
  */
 
 #include "i915_drv.h"
+#include "gvt.h"
 
 #define GMBUS1_TOTAL_BYTES_SHIFT 16
 #define GMBUS1_TOTAL_BYTES_MASK 0x1ff
diff --git a/drivers/gpu/drm/i915/gvt/execlist.c 
b/drivers/gpu/drm/i915/gvt/execlist.c
index c50a3d1..b87b4f5 100644
--- a/drivers/gpu/drm/i915/gvt/execlist.c
+++ b/drivers/gpu/drm/i915/gvt/execlist.c
@@ -33,6 +33,7 @@
  */
 
 #include "i915_drv.h"
+#include "gvt.h"
 
 #define _EL_OFFSET_STATUS   0x234
 #define _EL_OFFSET_STATUS_BUF   0x370
diff --git a/drivers/gpu/drm/i915/gvt/firmware.c 
b/drivers/gpu/drm/i915/gvt/firmware.c
index 4578a4d..d068a52 100644
--- a/drivers/gpu/drm/i915/gvt/firmware.c
+++ b/drivers/gpu/drm/i915/gvt/firmware.c
@@ -32,6 +32,8 @@
 #include 
 
 #include "i915_drv.h"
+#include "gvt.h"
+#include "i915_pvinfo.h"
 
 #define FIRMWARE_VERSION (0x0)
 
diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
index 29de179..0722d1e 100644
--- a/drivers/gpu/drm/i915/gvt/gtt.c
+++ b/drivers/gpu/drm/i915/gvt/gtt.c
@@ -34,6 +34,8 @@
  */
 
 #include "i915_drv.h"
+#include "gvt.h"
+#include "i915_pvinfo.h"
 #include "trace.h"
 
 static bool enable_out_of_sync = false;
diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c
index e72e26c..aee5ceb 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.c
+++ b/drivers/gpu/drm/i915/gvt/gvt.c
@@ -35,6 +35,7 @@
 #include 
 
 #include "i915_drv.h"
+#include "gvt.h"
 
 struct intel_gvt_host intel_gvt_host;
 
@@ -173,7 +174,7 @@ static int init_service_thread(struct intel_gvt *gvt)
  */
 void intel_gvt_clean_device(struct drm_i915_private *dev_priv)
 {
-   struct intel_gvt *gvt = _priv->gvt;
+   struct intel_gvt *gvt = to_gvt(dev_priv);
 
if (WARN_ON(!gvt->initialized))
return;
@@ -188,6 +189,8 @@ void intel_gvt_clean_device(struct drm_i915_private 
*dev_priv)
intel_gvt_clean_mmio_info(gvt);

Re: [Intel-gfx] [PATCH v3] drm/i915/gvt: clean up intel_gvt.h as interface for i915 core

[Chris Wilson]

On Thu, Oct 20, 2016 at 04:26:14PM +0800, Zhenyu Wang wrote:
>  int intel_gvt_init_device(struct drm_i915_private *dev_priv)
>  {
> - struct intel_gvt *gvt = _priv->gvt;
> + struct intel_gvt *gvt;
>   int ret;
>  
>   /*
> @@ -214,9 +216,13 @@ int intel_gvt_init_device(struct drm_i915_private 
> *dev_priv)
>   if (WARN_ON(!intel_gvt_host.initialized))
>   return -EINVAL;
>  
> - if (WARN_ON(gvt->initialized))
> + if (WARN_ON(dev_priv->gvt))

This is the odd one out

if (WARN_ON(to_gvt(dev_priv)) ?

On the other hand it matches with the assignment. but you could do
to_gvt(dev_priv) = gvt; there, that's getting ugly. So I think the
current code is sensible.

> +#define to_gvt(dev_priv) (struct intel_gvt *)((dev_priv)->gvt)

You can now dispense with the cast. I'd prefer if this was an inline for
clearer type checking.

static inline struct intel_gvt *to_gvt(struct drm_i915_private *i915)
{
return i915->gvt;
}

Tidy up to_gvt() (whatever takes your fancy) and
Reviewed-by: Chris Wilson 
-Chris

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

Re: [Intel-gfx] [PATCH 5/7] drm/i915: Update kerneldoc for intel_dpll_mgr.c

[Ander Conselvan De Oliveira]

On Thu, 2016-10-20 at 11:19 +0300, Jani Nikula wrote:
> On Thu, 20 Oct 2016, Daniel Vetter  wrote:
> > 
> > On Wed, Oct 19, 2016 at 06:29:13PM +0300, Jani Nikula wrote:
> > > 
> > > On Wed, 19 Oct 2016, Ander Conselvan De Oliveira 
> > > wrote:
> > > > 
> > > > On Thu, 2016-10-13 at 15:46 +0200, Daniel Vetter wrote:
> > > > > 
> > > > > > 
> > > > > > +   /**
> > > > > > +    * @hw_state: hardware configuration for the DPLL.
> > > > > "... stored in struct _dpll_hw_state." - I love my hyperlinks ;-
> > > > > )
> > > > I'll add that, but I think it's silly. The type of the field is struct
> > > > intel_dpll_hw_state, so I think it would be more natural if the
> > > > documentation
> > > > tool would add that link automatically.
> > > Agreed.
> > Someone volunteering? I'd hope it would be at most a bit of shuffling with
> > the generator, we should have the type and all that handy already. Except
> > maybe lots of corner-cases ...
> I think the problem was that I couldn't figure out how to make Sphinx do
> cross references within inline preformatted text. And I thought that was
> less important than fixing up the struct presentation that I'm not all
> too happy about currently. See [1] first. I don't think we need to have
> both the definition and members. It's just wasted vertical space.
> 
> I'd suggest we drop the definition altogether, and have the members list
> contain the member types, ideally with cross-references. If that means
> having to use normal font instead of monospace, I'd go with it anyway.
> 
> Thoughts?

I think that makes sense. There's no extra information there (and if you forget
to add a kerneldoc tag to a field, it isn't even listed). The definition is in
the code anyway.

I was actually a bit surprised to see the definition in the doc the first time.

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

[Intel-gfx] i915 and GTV-g maintenance, workflows and CI

[Jani Nikula]

We need to formalize the process between i915 proper and GVT-g a bit
more, and address some of the current shortcomings and issues in the
process and GVT-g CI.

This started off internally as a random list of items, I'm including
some of the current status as well. Please comment, as some of the stuff
here are just my opinions.

* How do we ensure GVT-g patches get the same kind of pre-merge CI
  coverage as we have for other i915 code? Could we at least make CI run
  tests on GVT-g pull requests before merging to drm-intel trees?

  => Work in progress to set up GVT-g CI.

* How do we handle fixes to GVT-g code? Do all fixes need to go via the
  GVT-g mailing lists and review? We're bound to get GVT-g patches on
  intel-gfx mailing list too. There's confusion already [1]. Mostly the
  GVT-g changes come from GVT-g maintainers as pull requests.

  [1] https://patchwork.freedesktop.org/series/14000/

* GVT-g related changes to i915 proper must be reviewed on intel-gfx
  mailing list, and must either be applied to drm-intel directly, or get
  an ack to be merged via GVT-g tree and pull requests.

* GVT-g needs to start annotating fixes with the Fixes: tags, preferably
  also cc: stable when we get that far, so our fixes plumbing can figure
  out which commits to backport.

  => GVT-g maintainers will take care of this.

* Should GVT-g have a MAINTAINERS entry of its own?

  => 
https://github.com/01org/gvt-linux/commit/41161c9e9e50a5bad98a0e74ad0878c352bdea40

+INTEL GVT-g DRIVERS (Intel GPU Virtualization)
+M:  Zhenyu Wang 
+M:  Zhi Wang 
+L:  igvt-g-...@lists.01.org
+L:  intel-gfx@lists.freedesktop.org
+W:  https://01.org/igvt-g
+T:  git https://github.com/01org/gvt-linux.git
+S:  Supported
+F:  drivers/gpu/drm/i915/gvt/

  I think we'll want to keep intel-gfx there, but mostly I think it's
  fine for the usual GVT-g development to happen on igvt-g-dev only.

* igvt-g-...@lists.01.org needs to start accepting mails from
  non-subscribers.

  => Work in progress.

* GVT-g needs to start paying more attention to compiler and sparse
  warnings.

  => GVT-G maintainers will take care of this.

* GVT-g could use some overview documentation under Documentation/gpu.

* GVT-g bug management. Do you have something set up already? Would be
  great to be able to use https://bugs.freedesktop.org so we could
  reassign between i915 and GVT-g.

What did I forget/overlook?

BR,
Jani.


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

[Intel-gfx] [PATCH igt] igt/drv_hangman: Use manual error-state generation

[Chris Wilson]

For the basic error state, we only desire that an error state be created
following a hang. For that purpose, we do not need a real hang (slow
6-12s) but can inject one instead (fast <1s).

Signed-off-by: Chris Wilson 
---
 tests/drv_hangman.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/tests/drv_hangman.c b/tests/drv_hangman.c
index 953a4c6..bfe5eaf 100644
--- a/tests/drv_hangman.c
+++ b/tests/drv_hangman.c
@@ -32,6 +32,8 @@
 #include 
 #include 
 
+#include "igt_debugfs.h"
+
 #ifndef I915_PARAM_CMD_PARSER_VERSION
 #define I915_PARAM_CMD_PARSER_VERSION   28
 #endif
@@ -166,15 +168,21 @@ static void test_error_state_basic(void)
 {
int fd;
 
-   fd = drm_open_driver(DRIVER_INTEL);
-
clear_error_state();
assert_error_state_clear();
 
-   submit_hang(fd, I915_EXEC_RENDER);
+   /* Manually trigger a hang by request a reset */
+   fd = igt_debugfs_open("i915_wedged", O_WRONLY);
+   igt_ignore_warn(write(fd, "1\n", 2));
+   close(fd);
+
+   /* Wait for the error capture and gpu reset to complete */
+   fd = drm_open_driver(DRIVER_INTEL);
+   gem_quiescent_gpu(fd);
close(fd);
 
assert_error_state_collected();
+
clear_error_state();
assert_error_state_clear();
 }
-- 
2.9.3

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

[Intel-gfx] [PATCH] drm/i915/gvt: clean up intel_gvt.h as interface for i915 core

[Zhenyu Wang]

i915 core should only call functions and structures exposed through
intel_gvt.h. Remove internal gvt.h and i915_pvinfo.h.

Change for internal intel_gvt structure as private handler which
not requires to expose gvt internal structure for i915 core.

Signed-off-by: Zhenyu Wang 
---
 drivers/gpu/drm/i915/gvt/aperture_gm.c  |  1 +
 drivers/gpu/drm/i915/gvt/cfg_space.c|  1 +
 drivers/gpu/drm/i915/gvt/cmd_parser.c   |  2 ++
 drivers/gpu/drm/i915/gvt/display.c  |  1 +
 drivers/gpu/drm/i915/gvt/edid.c |  1 +
 drivers/gpu/drm/i915/gvt/execlist.c |  1 +
 drivers/gpu/drm/i915/gvt/firmware.c |  2 ++
 drivers/gpu/drm/i915/gvt/gtt.c  |  2 ++
 drivers/gpu/drm/i915/gvt/gvt.c  | 14 +++---
 drivers/gpu/drm/i915/gvt/gvt.h  |  2 ++
 drivers/gpu/drm/i915/gvt/handlers.c |  2 ++
 drivers/gpu/drm/i915/gvt/interrupt.c|  1 +
 drivers/gpu/drm/i915/gvt/mmio.c |  1 +
 drivers/gpu/drm/i915/gvt/opregion.c |  1 +
 drivers/gpu/drm/i915/gvt/render.c   |  1 +
 drivers/gpu/drm/i915/gvt/sched_policy.c |  1 +
 drivers/gpu/drm/i915/gvt/scheduler.c|  5 +++--
 drivers/gpu/drm/i915/gvt/vgpu.c |  2 ++
 drivers/gpu/drm/i915/i915_drv.h |  4 ++--
 drivers/gpu/drm/i915/intel_gvt.c|  1 +
 drivers/gpu/drm/i915/intel_gvt.h|  3 ---
 21 files changed, 39 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/aperture_gm.c 
b/drivers/gpu/drm/i915/gvt/aperture_gm.c
index e0211f8..db503c1 100644
--- a/drivers/gpu/drm/i915/gvt/aperture_gm.c
+++ b/drivers/gpu/drm/i915/gvt/aperture_gm.c
@@ -35,6 +35,7 @@
  */
 
 #include "i915_drv.h"
+#include "gvt.h"
 
 #define MB_TO_BYTES(mb) ((mb) << 20ULL)
 #define BYTES_TO_MB(b) ((b) >> 20ULL)
diff --git a/drivers/gpu/drm/i915/gvt/cfg_space.c 
b/drivers/gpu/drm/i915/gvt/cfg_space.c
index 16360e4..4c68774 100644
--- a/drivers/gpu/drm/i915/gvt/cfg_space.c
+++ b/drivers/gpu/drm/i915/gvt/cfg_space.c
@@ -32,6 +32,7 @@
  */
 
 #include "i915_drv.h"
+#include "gvt.h"
 
 enum {
INTEL_GVT_PCI_BAR_GTTMMIO = 0,
diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.c 
b/drivers/gpu/drm/i915/gvt/cmd_parser.c
index 5808ee7..5b4658f 100644
--- a/drivers/gpu/drm/i915/gvt/cmd_parser.c
+++ b/drivers/gpu/drm/i915/gvt/cmd_parser.c
@@ -36,6 +36,8 @@
 
 #include 
 #include "i915_drv.h"
+#include "gvt.h"
+#include "i915_pvinfo.h"
 #include "trace.h"
 
 #define INVALID_OP(~0U)
diff --git a/drivers/gpu/drm/i915/gvt/display.c 
b/drivers/gpu/drm/i915/gvt/display.c
index 534000b..d8908d4 100644
--- a/drivers/gpu/drm/i915/gvt/display.c
+++ b/drivers/gpu/drm/i915/gvt/display.c
@@ -33,6 +33,7 @@
  */
 
 #include "i915_drv.h"
+#include "gvt.h"
 
 static int get_edp_pipe(struct intel_vgpu *vgpu)
 {
diff --git a/drivers/gpu/drm/i915/gvt/edid.c b/drivers/gpu/drm/i915/gvt/edid.c
index a07e427..7e1da1c 100644
--- a/drivers/gpu/drm/i915/gvt/edid.c
+++ b/drivers/gpu/drm/i915/gvt/edid.c
@@ -33,6 +33,7 @@
  */
 
 #include "i915_drv.h"
+#include "gvt.h"
 
 #define GMBUS1_TOTAL_BYTES_SHIFT 16
 #define GMBUS1_TOTAL_BYTES_MASK 0x1ff
diff --git a/drivers/gpu/drm/i915/gvt/execlist.c 
b/drivers/gpu/drm/i915/gvt/execlist.c
index c50a3d1..b87b4f5 100644
--- a/drivers/gpu/drm/i915/gvt/execlist.c
+++ b/drivers/gpu/drm/i915/gvt/execlist.c
@@ -33,6 +33,7 @@
  */
 
 #include "i915_drv.h"
+#include "gvt.h"
 
 #define _EL_OFFSET_STATUS   0x234
 #define _EL_OFFSET_STATUS_BUF   0x370
diff --git a/drivers/gpu/drm/i915/gvt/firmware.c 
b/drivers/gpu/drm/i915/gvt/firmware.c
index 4578a4d..d068a52 100644
--- a/drivers/gpu/drm/i915/gvt/firmware.c
+++ b/drivers/gpu/drm/i915/gvt/firmware.c
@@ -32,6 +32,8 @@
 #include 
 
 #include "i915_drv.h"
+#include "gvt.h"
+#include "i915_pvinfo.h"
 
 #define FIRMWARE_VERSION (0x0)
 
diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
index 29de179..0722d1e 100644
--- a/drivers/gpu/drm/i915/gvt/gtt.c
+++ b/drivers/gpu/drm/i915/gvt/gtt.c
@@ -34,6 +34,8 @@
  */
 
 #include "i915_drv.h"
+#include "gvt.h"
+#include "i915_pvinfo.h"
 #include "trace.h"
 
 static bool enable_out_of_sync = false;
diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c
index e72e26c..be9ccc8 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.c
+++ b/drivers/gpu/drm/i915/gvt/gvt.c
@@ -35,6 +35,7 @@
 #include 
 
 #include "i915_drv.h"
+#include "gvt.h"
 
 struct intel_gvt_host intel_gvt_host;
 
@@ -173,7 +174,7 @@ static int init_service_thread(struct intel_gvt *gvt)
  */
 void intel_gvt_clean_device(struct drm_i915_private *dev_priv)
 {
-   struct intel_gvt *gvt = _priv->gvt;
+   struct intel_gvt *gvt = to_gvt(dev_priv);
 
if (WARN_ON(!gvt->initialized))
return;
@@ -204,7 +205,7 @@ void intel_gvt_clean_device(struct drm_i915_private 
*dev_priv)
  */
 int intel_gvt_init_device(struct drm_i915_private *dev_priv)
 {
-   struct intel_gvt *gvt = _priv->gvt;
+   struct intel_gvt *gvt;
int ret;
 
/*
@@ -214,9 +215,15 @@ int 

[Intel-gfx] [PATCH] Documentation/gpu: Add section for Intel GVT-g host support

[Zhenyu Wang]

Update with brief overview and reference for more detailed
arch design documents.

Add new section for Intel GVT-g host support.

Signed-off-by: Zhenyu Wang 
---
 Documentation/gpu/i915.rst   | 9 +
 drivers/gpu/drm/i915/intel_gvt.c | 8 ++--
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 87aaffc..95ce77f 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -49,6 +49,15 @@ Intel GVT-g Guest Support(vGPU)
 .. kernel-doc:: drivers/gpu/drm/i915/i915_vgpu.c
:internal:
 
+Intel GVT-g Host Support(vGPU device model)
+---
+
+.. kernel-doc:: drivers/gpu/drm/i915/intel_gvt.c
+   :doc: Intel GVT-g host support
+
+.. kernel-doc:: drivers/gpu/drm/i915/intel_gvt.c
+   :internal:
+
 Display Hardware Handling
 =
 
diff --git a/drivers/gpu/drm/i915/intel_gvt.c b/drivers/gpu/drm/i915/intel_gvt.c
index bae1a7d..88126b6 100644
--- a/drivers/gpu/drm/i915/intel_gvt.c
+++ b/drivers/gpu/drm/i915/intel_gvt.c
@@ -31,8 +31,12 @@
  * GPU among multiple virtual machines on a time-sharing basis. Each
  * virtual machine is presented a virtual GPU (vGPU), which has equivalent
  * features as the underlying physical GPU (pGPU), so i915 driver can run
- * seamlessly in a virtual machine. This file provides the englightments
- * of GVT and the necessary components used by GVT in i915 driver.
+ * seamlessly in a virtual machine.
+ *
+ * To virtualize GPU resources GVT-g driver depends on hypervisor technology
+ * e.g KVM/VFIO/mdev, Xen, etc. to provide resource access trapping capability
+ * and be virtualized within GVT-g device module. More architectural design
+ * doc is available on https://01.org/group/2230/documentation-list.
  */
 
 static bool is_supported_device(struct drm_i915_private *dev_priv)
-- 
2.9.3

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

Re: [Intel-gfx] [PATCH v2] drm/i915/gvt: clean up intel_gvt.h as interface for i915 core

[Chris Wilson]

On Thu, Oct 20, 2016 at 04:02:39PM +0800, Zhenyu Wang wrote:
>  void intel_gvt_clean_device(struct drm_i915_private *dev_priv)
>  {
> - struct intel_gvt *gvt = _priv->gvt;
> + struct intel_gvt *gvt = to_gvt(dev_priv);
>  
>   if (WARN_ON(!gvt->initialized))
>   return;
> @@ -188,6 +189,8 @@ void intel_gvt_clean_device(struct drm_i915_private 
> *dev_priv)
>   intel_gvt_clean_mmio_info(gvt);
>   intel_gvt_free_firmware(gvt);
>  
> + kfree(dev_priv->gvt);
> + dev_priv->gvt = NULL;
>   gvt->initialized = false;
>  }

Whoops. First a NULL pointer deref then a use-after-free before coffee.
I need coffee!

Just remove struct intel_gvt.initialized, it is leading you astray.
-Chris

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

Re: [Intel-gfx] [PATCH 5/7] drm/i915: Update kerneldoc for intel_dpll_mgr.c

[Jani Nikula]

On Thu, 20 Oct 2016, Daniel Vetter  wrote:
> On Wed, Oct 19, 2016 at 06:29:13PM +0300, Jani Nikula wrote:
>> On Wed, 19 Oct 2016, Ander Conselvan De Oliveira  
>> wrote:
>> > On Thu, 2016-10-13 at 15:46 +0200, Daniel Vetter wrote:
>> >> > +   /**
>> >> > +    * @hw_state: hardware configuration for the DPLL.
>> >> "... stored in struct _dpll_hw_state." - I love my hyperlinks ;-)
>> >
>> > I'll add that, but I think it's silly. The type of the field is struct
>> > intel_dpll_hw_state, so I think it would be more natural if the 
>> > documentation
>> > tool would add that link automatically.
>> 
>> Agreed.
>
> Someone volunteering? I'd hope it would be at most a bit of shuffling with
> the generator, we should have the type and all that handy already. Except
> maybe lots of corner-cases ...

I think the problem was that I couldn't figure out how to make Sphinx do
cross references within inline preformatted text. And I thought that was
less important than fixing up the struct presentation that I'm not all
too happy about currently. See [1] first. I don't think we need to have
both the definition and members. It's just wasted vertical space.

I'd suggest we drop the definition altogether, and have the members list
contain the member types, ideally with cross-references. If that means
having to use normal font instead of monospace, I'd go with it anyway.

Thoughts?

BR,
Jani.


[1] 
https://01.org/linuxgraphics/gfx-docs/drm/driver-api/infrastructure.html#c.device_driver

>
> And ack on the struct layout bikeshed I had.
> -Daniel

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

Re: [Intel-gfx] [PATCH] drm/i915/dp: add lane_count check in intel_dp_check_link_status

[Ville Syrjälä]

On Wed, Oct 19, 2016 at 10:29:53PM +0100, Matthew Auld wrote:
> Currently it's entirely possible to go through the link training step
> without first determining the lane_count, which is silly since we end up
> doing a bunch of aux transfers of size = 0, as highlighted by
> WARN_ON(!msg->buffer != !msg->size), and can only ever result in a
> 'failed to update link training' message. This can be observed during
> intel_dp_long_pulse where we can do the link training step, but before
> we have had a chance to set the link params. To avoid this we add an
> extra check for the lane_count in intel_dp_check_link_status, which
> should prevent us from doing the link training step prematurely.
> 
> v2: add WARN_ON_ONCE and FIXME comment (Ville)
> 
> References: https://bugs.freedesktop.org/show_bug.cgi?id=97344
> Cc: Ville Syrjälä 
> Cc: Mika Kahola 
> Signed-off-by: Matthew Auld 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 88f3b74..fb760ad 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4032,6 +4032,11 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
>   if (!to_intel_crtc(intel_encoder->base.crtc)->active)
>   return;
>  
> + /* FIXME: we need to synchronize this sort of stuff with hardware
> +  * readout */
> + if (WARN_ON_ONCE(!intel_dp->lane_count))
> + return;

One warn is better than a constant spew as can be seen eg. in
https://bugs.freedesktop.org/show_bug.cgi?id=98323

Still need to fix the real issue of course, but in the meantime

Reviewed-by: Ville Syrjälä 

> +
>   /* if link training is requested we should perform it always */
>   if ((intel_dp->compliance_test_type == DP_TEST_LINK_TRAINING) ||
>   (!drm_dp_channel_eq_ok(link_status, intel_dp->lane_count))) {
> -- 
> 2.7.4

-- 
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 igt] igt: drop gem_storedw_loop from BAT

[Petri Latvala]

On Wed, Oct 19, 2016 at 08:26:17PM +0100, Chris Wilson wrote:
> The inter-engine synchronisation (with and without semaphores) is
> equally exercised by gem_sync, so leave gem_storedw_loop out of the
> "quick" set.


How equally is "equally"? Is the test actually redundant, should it be
removed altogether?


--
Petri Latvala





> 
> Signed-off-by: Chris Wilson 
> ---
>  tests/gem_storedw_loop.c  | 6 +++---
>  tests/intel-ci/fast-feedback.testlist | 7 ---
>  2 files changed, 3 insertions(+), 10 deletions(-)
> 
> diff --git a/tests/gem_storedw_loop.c b/tests/gem_storedw_loop.c
> index 317b8c6..4f05b21 100644
> --- a/tests/gem_storedw_loop.c
> +++ b/tests/gem_storedw_loop.c
> @@ -185,14 +185,14 @@ igt_main
>   }
>  
>   for (e = intel_execution_engines; e->name; e++) {
> - igt_subtest_f("basic-%s", e->name) {
> + igt_subtest_f("short-%s", e->name) {
>   check_test_requirements(fd, e->exec_id);
> - store_test(fd, e->exec_id | e->flags, 16*1024);
> + store_test(fd, e->exec_id | e->flags, 4*1024);
>   }
>  
>   igt_subtest_f("long-%s", e->name) {
>   check_test_requirements(fd, e->exec_id);
> - store_test(fd, e->exec_id | e->flags, 1024*1024);
> + store_test(fd, e->exec_id | e->flags, 4*1024*1024);
>   }
>   }
>  
> diff --git a/tests/intel-ci/fast-feedback.testlist 
> b/tests/intel-ci/fast-feedback.testlist
> index 853b911..b8fce59 100644
> --- a/tests/intel-ci/fast-feedback.testlist
> +++ b/tests/intel-ci/fast-feedback.testlist
> @@ -111,13 +111,6 @@ igt@gem_ringfill@basic-default
>  igt@gem_ringfill@basic-default-forked
>  igt@gem_ringfill@basic-default-hang
>  igt@gem_ringfill@basic-default-interruptible
> -igt@gem_storedw_loop@basic-blt
> -igt@gem_storedw_loop@basic-bsd
> -igt@gem_storedw_loop@basic-bsd1
> -igt@gem_storedw_loop@basic-bsd2
> -igt@gem_storedw_loop@basic-default
> -igt@gem_storedw_loop@basic-render
> -igt@gem_storedw_loop@basic-vebox
>  igt@gem_sync@basic-all
>  igt@gem_sync@basic-each
>  igt@gem_sync@basic-many-each
> -- 
> 2.9.3
> 
> ___
> 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] gvt gem fixes

[Daniel Vetter]

On Thu, Oct 20, 2016 at 03:15:33PM +0800, Zhenyu Wang wrote:
> On 2016.10.20 09:02:45 +0200, Daniel Vetter wrote:
> > Yeah, I think anything that touches i915 code should get merged through
> > drm-intel directly with the usual process. Only exception is when gvt has
> > a functional depency and it's a small patch, then I think we can sometimes
> > merge i915 core patches through gvt, with an ack from Jani or me (and
> > still proper review and CI and everything ofc). But that should be the
> > rare exception.
> 
> That's fair enough for me. One prepared change is to fix gvt header
> issue you've listed. As it touches intel_gvt.h in i915, I'll send that
> seperately first 
> (https://github.com/01org/gvt-linux/commit/b6a1ca7571ae45186394e555dc420481c1a9dba5)

Yes, anything touching code/files outside of the gvt/ sub-directory needs
to be submitted here to intel-gfx and go through our normal drm-intel
review process.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915/gvt: clean up intel_gvt.h as interface for i915 core

[Zhenyu Wang]

On 2016.10.20 09:12:02 +0100, Chris Wilson wrote:
> On Thu, Oct 20, 2016 at 04:02:39PM +0800, Zhenyu Wang wrote:
> >  void intel_gvt_clean_device(struct drm_i915_private *dev_priv)
> >  {
> > -   struct intel_gvt *gvt = _priv->gvt;
> > +   struct intel_gvt *gvt = to_gvt(dev_priv);
> >  
> > if (WARN_ON(!gvt->initialized))
> > return;
> > @@ -188,6 +189,8 @@ void intel_gvt_clean_device(struct drm_i915_private 
> > *dev_priv)
> > intel_gvt_clean_mmio_info(gvt);
> > intel_gvt_free_firmware(gvt);
> >  
> > +   kfree(dev_priv->gvt);
> > +   dev_priv->gvt = NULL;
> > gvt->initialized = false;
> >  }
> 
> Whoops. First a NULL pointer deref then a use-after-free before coffee.
> I need coffee!
> 
> Just remove struct intel_gvt.initialized, it is leading you astray.

oops! sorry about that...

-- 
Open Source Technology Center, Intel ltd.

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


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

Re: [Intel-gfx] [PATCH 1/8] drm/i915/skl+: Prepare for removing data rate from skl watermark state

[Maarten Lankhorst]

Op 20-10-16 om 00:13 schreef Matt Roper:
> On Wed, Oct 12, 2016 at 03:28:14PM +0200, Maarten Lankhorst wrote:
>> Caching is not required, drm_atomic_crtc_state_for_each_plane_state
>> can be used to inspect all plane_states that are assigned to the
>> current crtc_state, so we can just recalculate every time.
>>
>> Signed-off-by: Maarten Lankhorst 
>> ---
>>  drivers/gpu/drm/i915/intel_pm.c | 27 ---
>>  1 file changed, 12 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_pm.c 
>> b/drivers/gpu/drm/i915/intel_pm.c
>> index 6af1587e9d84..b96a899c899d 100644
>> --- a/drivers/gpu/drm/i915/intel_pm.c
>> +++ b/drivers/gpu/drm/i915/intel_pm.c
>> @@ -31,6 +31,7 @@
>>  #include "intel_drv.h"
>>  #include "../../../platform/x86/intel_ips.h"
>>  #include 
>> +#include 
>>  
>>  /**
>>   * DOC: RC6
>> @@ -3242,18 +3243,17 @@ skl_get_total_relative_data_rate(struct 
>> intel_crtc_state *intel_cstate)
>>  struct drm_crtc *crtc = cstate->crtc;
>>  struct drm_device *dev = crtc->dev;
>>  struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
>> -const struct drm_plane *plane;
>> +struct drm_plane *plane;
>>  const struct intel_plane *intel_plane;
>> -struct drm_plane_state *pstate;
>> +const struct drm_plane_state *pstate;
>>  unsigned int rate, total_data_rate = 0;
>>  int id;
>> -int i;
>>  
>>  if (WARN_ON(!state))
>>  return 0;
>>  
>>  /* Calculate and cache data rate for each plane */
>> -for_each_plane_in_state(state, plane, pstate, i) {
>> +drm_atomic_crtc_state_for_each_plane_state(plane, pstate, cstate) {
>>  id = skl_wm_plane_id(to_intel_plane(plane));
>>  intel_plane = to_intel_plane(plane);
>>  
>> @@ -3356,7 +3356,7 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
>>  struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
>>  struct intel_plane *intel_plane;
>>  struct drm_plane *plane;
>> -struct drm_plane_state *pstate;
>> +const struct drm_plane_state *pstate;
>>  enum pipe pipe = intel_crtc->pipe;
>>  struct skl_ddb_entry *alloc = >wm.skl.ddb;
>>  uint16_t alloc_size, start, cursor_blocks;
>> @@ -3392,14 +3392,14 @@ skl_allocate_pipe_ddb(struct intel_crtc_state 
>> *cstate,
>>  alloc_size -= cursor_blocks;
>>  
>>  /* 1. Allocate the mininum required blocks for each active plane */
>> -for_each_plane_in_state(state, plane, pstate, i) {
>> +drm_atomic_crtc_state_for_each_plane_state(plane, pstate, 
>> >base) {
>>  intel_plane = to_intel_plane(plane);
>>  id = skl_wm_plane_id(intel_plane);
>>  
>>  if (intel_plane->pipe != pipe)
>>  continue;
>>  
>> -if (!to_intel_plane_state(pstate)->base.visible) {
>> +if (!pstate->visible) {
>>  minimum[id] = 0;
>>  y_minimum[id] = 0;
>>  continue;
>> @@ -3948,7 +3948,7 @@ skl_ddb_add_affected_planes(struct intel_crtc_state 
>> *cstate)
>>  
>>  WARN_ON(!drm_atomic_get_existing_crtc_state(state, crtc));
>>  
>> -drm_for_each_plane_mask(plane, dev, crtc->state->plane_mask) {
>> +drm_for_each_plane_mask(plane, dev, cstate->base.plane_mask) {
> Is this change necessary?  Any plane that differs between the two masks
> should already be part of our state, so I don't think this changes the
> behavior at all.  The original 'crtc->state->plane_mask' form is closer
> to the drm_atomic_add_affected_planes() that this function is modeled
> after so my slight preference would be to leave it alone for
> consistency.
>
> Aside from that, this patch is
Not completely, but I was removing it since I'm trying to get rid of all 
pointers to obj->state as much as I can.
All accesses should be through some wrapper functions, still working out the 
specifics.

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

[Intel-gfx] [PATCH v3] drm/i915/gvt: clean up intel_gvt.h as interface for i915 core

[Zhenyu Wang]

i915 core should only call functions and structures exposed through
intel_gvt.h. Remove internal gvt.h and i915_pvinfo.h.

Change for internal intel_gvt structure as private handler which
not requires to expose gvt internal structure for i915 core.

v2: Fix per Chris's comment
- carefully handle dev_priv->gvt assignment
- add necessary bracket for macro helper
- forward declartion struct intel_gvt
- keep free operation within same file handling alloc

v3: fix use after free and remove intel_gvt.initialized

Signed-off-by: Zhenyu Wang 
---
 drivers/gpu/drm/i915/gvt/aperture_gm.c  |  1 +
 drivers/gpu/drm/i915/gvt/cfg_space.c|  1 +
 drivers/gpu/drm/i915/gvt/cmd_parser.c   |  2 ++
 drivers/gpu/drm/i915/gvt/display.c  |  1 +
 drivers/gpu/drm/i915/gvt/edid.c |  1 +
 drivers/gpu/drm/i915/gvt/execlist.c |  1 +
 drivers/gpu/drm/i915/gvt/firmware.c |  2 ++
 drivers/gpu/drm/i915/gvt/gtt.c  |  2 ++
 drivers/gpu/drm/i915/gvt/gvt.c  | 19 +--
 drivers/gpu/drm/i915/gvt/gvt.h  |  4 ++--
 drivers/gpu/drm/i915/gvt/handlers.c |  2 ++
 drivers/gpu/drm/i915/gvt/interrupt.c|  1 +
 drivers/gpu/drm/i915/gvt/mmio.c |  1 +
 drivers/gpu/drm/i915/gvt/opregion.c |  1 +
 drivers/gpu/drm/i915/gvt/render.c   |  1 +
 drivers/gpu/drm/i915/gvt/sched_policy.c |  1 +
 drivers/gpu/drm/i915/gvt/scheduler.c|  5 +++--
 drivers/gpu/drm/i915/gvt/vgpu.c |  2 ++
 drivers/gpu/drm/i915/i915_drv.h |  4 ++--
 drivers/gpu/drm/i915/intel_gvt.h|  3 +--
 20 files changed, 41 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/aperture_gm.c 
b/drivers/gpu/drm/i915/gvt/aperture_gm.c
index e0211f8..db503c1 100644
--- a/drivers/gpu/drm/i915/gvt/aperture_gm.c
+++ b/drivers/gpu/drm/i915/gvt/aperture_gm.c
@@ -35,6 +35,7 @@
  */
 
 #include "i915_drv.h"
+#include "gvt.h"
 
 #define MB_TO_BYTES(mb) ((mb) << 20ULL)
 #define BYTES_TO_MB(b) ((b) >> 20ULL)
diff --git a/drivers/gpu/drm/i915/gvt/cfg_space.c 
b/drivers/gpu/drm/i915/gvt/cfg_space.c
index 16360e4..4c68774 100644
--- a/drivers/gpu/drm/i915/gvt/cfg_space.c
+++ b/drivers/gpu/drm/i915/gvt/cfg_space.c
@@ -32,6 +32,7 @@
  */
 
 #include "i915_drv.h"
+#include "gvt.h"
 
 enum {
INTEL_GVT_PCI_BAR_GTTMMIO = 0,
diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.c 
b/drivers/gpu/drm/i915/gvt/cmd_parser.c
index 5808ee7..5b4658f 100644
--- a/drivers/gpu/drm/i915/gvt/cmd_parser.c
+++ b/drivers/gpu/drm/i915/gvt/cmd_parser.c
@@ -36,6 +36,8 @@
 
 #include 
 #include "i915_drv.h"
+#include "gvt.h"
+#include "i915_pvinfo.h"
 #include "trace.h"
 
 #define INVALID_OP(~0U)
diff --git a/drivers/gpu/drm/i915/gvt/display.c 
b/drivers/gpu/drm/i915/gvt/display.c
index 534000b..d8908d4 100644
--- a/drivers/gpu/drm/i915/gvt/display.c
+++ b/drivers/gpu/drm/i915/gvt/display.c
@@ -33,6 +33,7 @@
  */
 
 #include "i915_drv.h"
+#include "gvt.h"
 
 static int get_edp_pipe(struct intel_vgpu *vgpu)
 {
diff --git a/drivers/gpu/drm/i915/gvt/edid.c b/drivers/gpu/drm/i915/gvt/edid.c
index a07e427..7e1da1c 100644
--- a/drivers/gpu/drm/i915/gvt/edid.c
+++ b/drivers/gpu/drm/i915/gvt/edid.c
@@ -33,6 +33,7 @@
  */
 
 #include "i915_drv.h"
+#include "gvt.h"
 
 #define GMBUS1_TOTAL_BYTES_SHIFT 16
 #define GMBUS1_TOTAL_BYTES_MASK 0x1ff
diff --git a/drivers/gpu/drm/i915/gvt/execlist.c 
b/drivers/gpu/drm/i915/gvt/execlist.c
index c50a3d1..b87b4f5 100644
--- a/drivers/gpu/drm/i915/gvt/execlist.c
+++ b/drivers/gpu/drm/i915/gvt/execlist.c
@@ -33,6 +33,7 @@
  */
 
 #include "i915_drv.h"
+#include "gvt.h"
 
 #define _EL_OFFSET_STATUS   0x234
 #define _EL_OFFSET_STATUS_BUF   0x370
diff --git a/drivers/gpu/drm/i915/gvt/firmware.c 
b/drivers/gpu/drm/i915/gvt/firmware.c
index 4578a4d..d068a52 100644
--- a/drivers/gpu/drm/i915/gvt/firmware.c
+++ b/drivers/gpu/drm/i915/gvt/firmware.c
@@ -32,6 +32,8 @@
 #include 
 
 #include "i915_drv.h"
+#include "gvt.h"
+#include "i915_pvinfo.h"
 
 #define FIRMWARE_VERSION (0x0)
 
diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
index 29de179..0722d1e 100644
--- a/drivers/gpu/drm/i915/gvt/gtt.c
+++ b/drivers/gpu/drm/i915/gvt/gtt.c
@@ -34,6 +34,8 @@
  */
 
 #include "i915_drv.h"
+#include "gvt.h"
+#include "i915_pvinfo.h"
 #include "trace.h"
 
 static bool enable_out_of_sync = false;
diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c
index e72e26c..31b59d4 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.c
+++ b/drivers/gpu/drm/i915/gvt/gvt.c
@@ -35,6 +35,7 @@
 #include 
 
 #include "i915_drv.h"
+#include "gvt.h"
 
 struct intel_gvt_host intel_gvt_host;
 
@@ -173,9 +174,9 @@ static int init_service_thread(struct intel_gvt *gvt)
  */
 void intel_gvt_clean_device(struct drm_i915_private *dev_priv)
 {
-   struct intel_gvt *gvt = _priv->gvt;
+   struct intel_gvt *gvt = to_gvt(dev_priv);
 
-   if (WARN_ON(!gvt->initialized))
+   if (WARN_ON(!gvt))
return;
 
clean_service_thread(gvt);
@@ 

Re: [Intel-gfx] [PATCH RESEND 9/9] drm/i915: set proper N/M in modeset

[Jani Nikula]

On Thu, 20 Oct 2016, "Yang, Libin"  wrote:
>> -Original Message-
>> From: Nikula, Jani
>> Sent: Wednesday, October 19, 2016 11:09 PM
>> To: Yang, Libin ; Lin, Mengdong
>> ; intel-gfx@lists.freedesktop.org
>> Cc: libin.y...@linux.intel.com; Pandiyan, Dhinakaran
>> ; Zhang, Keqiao
>> ; Zhao, Juan J 
>> Subject: RE: [Intel-gfx] [PATCH RESEND 9/9] drm/i915: set proper N/M in
>> modeset
>> 
>> 
>> Sorry it's taken me forever to get back to this. Some comments inline.
>> 
>> BR,
>> Jani.
>> 
>> On Wed, 12 Oct 2016, "Yang, Libin"  wrote:
>> >> -Original Message-
>> >> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On
>> >> Behalf Of Lin, Mengdong
>> >> Sent: Wednesday, October 12, 2016 10:46 AM
>> >> To: Nikula, Jani ;
>> >> intel-gfx@lists.freedesktop.org
>> >> Cc: Nikula, Jani ; libin.y...@linux.intel.com;
>> >> Pandiyan, Dhinakaran 
>> >> Subject: Re: [Intel-gfx] [PATCH RESEND 9/9] drm/i915: set proper N/M
>> >> in modeset
>> >>
>> >>
>> >>
>> >> > -Original Message-
>> >> > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On
>> >> > Behalf Of Jani Nikula
>> >> > Sent: Monday, October 10, 2016 11:04 PM
>> >> > To: intel-gfx@lists.freedesktop.org
>> >> > Cc: Nikula, Jani ;
>> >> > libin.y...@linux.intel.com; Pandiyan, Dhinakaran
>> >> > 
>> >> > Subject: [Intel-gfx] [PATCH RESEND 9/9] drm/i915: set proper N/M in
>> >> > modeset
>> >> >
>> >> > When modeset occurs and the LS_CLK is set to some special values in
>> >> > DP mode, the N/M need to be set manually if audio is playing.
>> >> > Otherwise the first several seconds may be silent in audio playback.
>> >> >
>> >> > The relationship of Maud and Naud is expressed in the following
>> equation:
>> >> > Maud/Naud = 512 * fs / f_LS_Clk
>> >> >
>> >> > Please refer VESA DisplayPort Standard spec for details.
>> >> >
>> >> > Signed-off-by: Libin Yang 
>> >> > Signed-off-by: Jani Nikula 
>> >> > ---
>> >> >  drivers/gpu/drm/i915/i915_reg.h|   7 +++
>> >> >  drivers/gpu/drm/i915/intel_audio.c | 100
>> >> > -
>> >> >  2 files changed, 105 insertions(+), 2 deletions(-)
>> >> >
>> >> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> >> > b/drivers/gpu/drm/i915/i915_reg.h index 595d196f753f..8d9dbc7d5b32
>> >> > 100644
>> >> > --- a/drivers/gpu/drm/i915/i915_reg.h
>> >> > +++ b/drivers/gpu/drm/i915/i915_reg.h
>> >> > @@ -7359,6 +7359,13 @@ enum {
>> >> >  #define _HSW_AUD_MISC_CTRL_B   0x65110
>> >> >  #define HSW_AUD_MISC_CTRL(pipe)_MMIO_PIPE(pipe,
>> >> > _HSW_AUD_MISC_CTRL_A, _HSW_AUD_MISC_CTRL_B)
>> >> >
>> >> > +#define _HSW_AUD_M_CTS_ENABLE_A0x65028
>> >> > +#define _HSW_AUD_M_CTS_ENABLE_B0x65128
>> >> > +#define HSW_AUD_M_CTS_ENABLE(pipe) _MMIO_PIPE(pipe,
>> >> > _HSW_AUD_M_CTS_ENABLE_A, _HSW_AUD_M_CTS_ENABLE_B)
>> >> > +#define   AUD_M_CTS_M_VALUE_INDEX  (1 << 21)
>> >> > +#define   AUD_M_CTS_M_PROG_ENABLE  (1 << 20)
>> >> > +#define   AUD_CONFIG_M_MASK0xf
>> >>
>> >> The last line cause misalignment after applying the patch.
>> >>
>> >> > +
>> >> >  #define _HSW_AUD_DIP_ELD_CTRL_ST_A 0x650b4
>> >> >  #define _HSW_AUD_DIP_ELD_CTRL_ST_B 0x651b4
>> >> >  #define HSW_AUD_DIP_ELD_CTRL(pipe) _MMIO_PIPE(pipe,
>> >> > _HSW_AUD_DIP_ELD_CTRL_ST_A, _HSW_AUD_DIP_ELD_CTRL_ST_B)
>> diff --
>> >> git
>> >> > a/drivers/gpu/drm/i915/intel_audio.c
>> >> > b/drivers/gpu/drm/i915/intel_audio.c
>> >> > index 81df29ca4947..0bc2701b6c9c 100644
>> >> > --- a/drivers/gpu/drm/i915/intel_audio.c
>> >> > +++ b/drivers/gpu/drm/i915/intel_audio.c
>> >> > @@ -57,6 +57,70 @@
>> >> >   * struct _audio_component_audio_ops @audio_ops is called
>> >> > from
>> >> > i915 driver.
>> >> >   */
>> >> >
>> >> > +/* DP N/M table */
>> >> > +#define LC_540M 54
>> >> > +#define LC_270M 27
>> >> > +#define LC_162M 162000
>> >> > +
>> >> > +struct dp_aud_n_m {
>> >> > +   int sample_rate;
>> >> > +   int clock;
>> >> > +   u16 n;
>> >> > +   u16 m;
>> >> > +};
>> >> > +
>> >> > +static const struct dp_aud_n_m dp_aud_n_m[] = {
>> >> > +   { 192000, LC_540M, 5625, 1024 },
>> >> > +   { 176400, LC_540M, 9375, 1568 },
>> >> > +   { 96000, LC_540M, 5625, 512 },
>> >> > +   { 88200, LC_540M, 9375, 784 },
>> >> > +   { 48000, LC_540M, 5625, 256 },
>> >> > +   { 44100, LC_540M, 9375, 392 },
>> >> > +   { 32000, LC_540M, 16875, 512 },
>> 
>> Any particular reason these M/N values are half of what they're in table
>> 2-104 of DP 1.4 spec? (Admittedly the table is an informative example.)
>
> For HDMI, we found only set N is 

Re: [Intel-gfx] [PATCH igt] igt/drv_hangman: Use manual error-state generation

[Daniel Vetter]

On Thu, Oct 20, 2016 at 10:07:39AM +0100, Chris Wilson wrote:
> For the basic error state, we only desire that an error state be created
> following a hang. For that purpose, we do not need a real hang (slow
> 6-12s) but can inject one instead (fast <1s).
> 
> Signed-off-by: Chris Wilson 

Should we instead speed up hangcheck? I think there's lots of value in
making sure not just error dumping, but also hang detection works somewhat
in BAT. Since if it doesn't any attempt at a full run will lead to pretty
serious disasters. And I have this dream that BAT is the gating thing
deciding whether a patch series deserves a complete pre-merge run ;-)

But since this is a controlled enviromnent we could make hangcheck
super-fast at timing out with some debugfs knob. Would probably also help
a lot with speeding up the gazillion of testcases in gem_reset_stats.
-Daniel

> ---
>  tests/drv_hangman.c | 14 +++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/tests/drv_hangman.c b/tests/drv_hangman.c
> index 953a4c6..bfe5eaf 100644
> --- a/tests/drv_hangman.c
> +++ b/tests/drv_hangman.c
> @@ -32,6 +32,8 @@
>  #include 
>  #include 
>  
> +#include "igt_debugfs.h"
> +
>  #ifndef I915_PARAM_CMD_PARSER_VERSION
>  #define I915_PARAM_CMD_PARSER_VERSION   28
>  #endif
> @@ -166,15 +168,21 @@ static void test_error_state_basic(void)
>  {
>   int fd;
>  
> - fd = drm_open_driver(DRIVER_INTEL);
> -
>   clear_error_state();
>   assert_error_state_clear();
>  
> - submit_hang(fd, I915_EXEC_RENDER);
> + /* Manually trigger a hang by request a reset */
> + fd = igt_debugfs_open("i915_wedged", O_WRONLY);
> + igt_ignore_warn(write(fd, "1\n", 2));
> + close(fd);
> +
> + /* Wait for the error capture and gpu reset to complete */
> + fd = drm_open_driver(DRIVER_INTEL);
> + gem_quiescent_gpu(fd);
>   close(fd);
>  
>   assert_error_state_collected();
> +
>   clear_error_state();
>   assert_error_state_clear();
>  }
> -- 
> 2.9.3
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH igt] igt: drop gem_storedw_loop from BAT

[Chris Wilson]

On Thu, Oct 20, 2016 at 11:16:16AM +0200, Daniel Vetter wrote:
> On Thu, Oct 20, 2016 at 09:54:33AM +0100, Chris Wilson wrote:
> > On Thu, Oct 20, 2016 at 11:45:47AM +0300, Petri Latvala wrote:
> > > On Wed, Oct 19, 2016 at 08:26:17PM +0100, Chris Wilson wrote:
> > > > The inter-engine synchronisation (with and without semaphores) is
> > > > equally exercised by gem_sync, so leave gem_storedw_loop out of the
> > > > "quick" set.
> > >
> > >
> > > How equally is "equally"? Is the test actually redundant, should it be
> > > removed altogether?
> >
> > The stress patterns exhibited by the test are identical to others in
> > BAT. The accuracy tests are covered by others in BAT. The actual flow
> > (edge coverage) will be subtly different and therefore the test is still
> > unique and may catch future bugs not caught by others. But as far as BAT
> > goes the likelihood of this catching something not caught by others
> > within BAT is very very small.
> 
> But given that we have 50k gem tests in full igt, does it really make
> sense to keep it? Imo there's not much point in keeping around every
> minute combinatorial variation if it means we can never run the full set
> of testcases. Some serious trimming of the herd is probably called for.

50k? I've 500k in gem_concurrent_all alone that I wish to be run...

Wishlist: fuzz testing of both the driver and gpu simultaneously.
-Chris

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

Re: [Intel-gfx] [PATCH 23/41] drm/i915: Move object release to a freelist + worker

[Chris Wilson]

On Tue, Oct 18, 2016 at 10:51:53AM +0100, John Harrison wrote:
> On 14/10/2016 13:18, Chris Wilson wrote:
> >@@ -338,11 +345,10 @@ i915_gem_get_tiling(struct drm_device *dev, void *data,
> > case I915_TILING_Y:
> > args->swizzle_mode = dev_priv->mm.bit_6_swizzle_y;
> > break;
> >+default:
> > case I915_TILING_NONE:
> > args->swizzle_mode = I915_BIT_6_SWIZZLE_NONE;
> > break;
> >-default:
> >-DRM_ERROR("unknown tiling mode\n");
> Why is this change still needed? Now that it returns early on lookup
> failure, there should be no need to ignore broken/unsupported tiling
> modes. So why silence the error message?

We do not emit *ERROR* (a driver error) under direct control of the
user.
-Chris

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

[Intel-gfx] [PATCH 4/5] drm/i915: Remove RPM sequence checking

[Chris Wilson]

We only used the RPM sequence checking inside the lowlevel GTT
accessors, when we had to rely on callers taking the wakeref on our
behalf. Now that we take the RPM wakeref inside the GTT management
routines themselves, we can forgo the sanitycheck of the callers.

Signed-off-by: Chris Wilson 
Cc: Imre Deak 
---
 drivers/gpu/drm/i915/i915_drv.h |  1 -
 drivers/gpu/drm/i915/i915_gem_gtt.c | 55 +
 drivers/gpu/drm/i915/intel_drv.h| 17 --
 drivers/gpu/drm/i915/intel_pm.c |  1 -
 drivers/gpu/drm/i915/intel_runtime_pm.c |  3 +-
 5 files changed, 2 insertions(+), 75 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c083ed37572b..c87074b8ef61 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1686,7 +1686,6 @@ struct skl_wm_level {
  */
 struct i915_runtime_pm {
atomic_t wakeref_count;
-   atomic_t atomic_seq;
bool suspended;
bool irqs_enabled;
 };
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 33036359c170..947d5ad51fb7 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2395,16 +2395,11 @@ static void gen8_ggtt_insert_page(struct 
i915_address_space *vm,
gen8_pte_t __iomem *pte =
(gen8_pte_t __iomem *)dev_priv->ggtt.gsm +
(offset >> PAGE_SHIFT);
-   int rpm_atomic_seq;
-
-   rpm_atomic_seq = assert_rpm_atomic_begin(dev_priv);
 
gen8_set_pte(pte, gen8_pte_encode(addr, level));
 
I915_WRITE(GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);
POSTING_READ(GFX_FLSH_CNTL_GEN6);
-
-   assert_rpm_atomic_end(dev_priv, rpm_atomic_seq);
 }
 
 static void gen8_ggtt_insert_entries(struct i915_address_space *vm,
@@ -2418,11 +2413,8 @@ static void gen8_ggtt_insert_entries(struct 
i915_address_space *vm,
gen8_pte_t __iomem *gtt_entries;
gen8_pte_t gtt_entry;
dma_addr_t addr;
-   int rpm_atomic_seq;
int i = 0;
 
-   rpm_atomic_seq = assert_rpm_atomic_begin(dev_priv);
-
gtt_entries = (gen8_pte_t __iomem *)ggtt->gsm + (start >> PAGE_SHIFT);
 
for_each_sgt_dma(addr, sgt_iter, st) {
@@ -2446,8 +2438,6 @@ static void gen8_ggtt_insert_entries(struct 
i915_address_space *vm,
 */
I915_WRITE(GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);
POSTING_READ(GFX_FLSH_CNTL_GEN6);
-
-   assert_rpm_atomic_end(dev_priv, rpm_atomic_seq);
 }
 
 struct insert_entries {
@@ -2486,16 +2476,11 @@ static void gen6_ggtt_insert_page(struct 
i915_address_space *vm,
gen6_pte_t __iomem *pte =
(gen6_pte_t __iomem *)dev_priv->ggtt.gsm +
(offset >> PAGE_SHIFT);
-   int rpm_atomic_seq;
-
-   rpm_atomic_seq = assert_rpm_atomic_begin(dev_priv);
 
iowrite32(vm->pte_encode(addr, level, flags), pte);
 
I915_WRITE(GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);
POSTING_READ(GFX_FLSH_CNTL_GEN6);
-
-   assert_rpm_atomic_end(dev_priv, rpm_atomic_seq);
 }
 
 /*
@@ -2515,11 +2500,8 @@ static void gen6_ggtt_insert_entries(struct 
i915_address_space *vm,
gen6_pte_t __iomem *gtt_entries;
gen6_pte_t gtt_entry;
dma_addr_t addr;
-   int rpm_atomic_seq;
int i = 0;
 
-   rpm_atomic_seq = assert_rpm_atomic_begin(dev_priv);
-
gtt_entries = (gen6_pte_t __iomem *)ggtt->gsm + (start >> PAGE_SHIFT);
 
for_each_sgt_dma(addr, sgt_iter, st) {
@@ -2542,8 +2524,6 @@ static void gen6_ggtt_insert_entries(struct 
i915_address_space *vm,
 */
I915_WRITE(GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);
POSTING_READ(GFX_FLSH_CNTL_GEN6);
-
-   assert_rpm_atomic_end(dev_priv, rpm_atomic_seq);
 }
 
 static void nop_clear_range(struct i915_address_space *vm,
@@ -2554,7 +2534,6 @@ static void nop_clear_range(struct i915_address_space *vm,
 static void gen8_ggtt_clear_range(struct i915_address_space *vm,
  uint64_t start, uint64_t length)
 {
-   struct drm_i915_private *dev_priv = to_i915(vm->dev);
struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
unsigned first_entry = start >> PAGE_SHIFT;
unsigned num_entries = length >> PAGE_SHIFT;
@@ -2562,9 +2541,6 @@ static void gen8_ggtt_clear_range(struct 
i915_address_space *vm,
(gen8_pte_t __iomem *)ggtt->gsm + first_entry;
const int max_entries = ggtt_total_entries(ggtt) - first_entry;
int i;
-   int rpm_atomic_seq;
-
-   rpm_atomic_seq = assert_rpm_atomic_begin(dev_priv);
 
if (WARN(num_entries > max_entries,
 "First entry = %d; Num entries = %d (max=%d)\n",
@@ -2576,15 +2552,12 @@ static void gen8_ggtt_clear_range(struct 
i915_address_space *vm,
for (i = 0; i < num_entries; i++)
gen8_set_pte(_base[i], scratch_pte);

[Intel-gfx] RPM vs struct mutex fixes

[Chris Wilson]

A little hiccup caught by 0day but not BAT having been resolved with
commit ebc0808fa2da ("drm/i915: Restrict pagefault disabling to just
around copy_from_user()"), let's try again.

I'm still puzzling over how BAT missed the warning.
-Chris

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

[Intel-gfx] [PATCH 1/5] drm/i915: Move user fault tracking to a separate list

[Chris Wilson]

We want to decouple RPM and struct_mutex, but currently RPM has to walk
the list of bound objects and remove userspace mmapping before we
suspend (otherwise userspace may continue to access the GTT whilst it is
powered down). This currently requires the struct_mutex to walk the
bound_list, but if we move that to a separate list and lock we can take
the first step towards removing the struct_mutex.

v2: Split runtime suspend unmapping vs regular unmapping, to make the
locking (and barriers) clearer. Add the object to the userfault_list
prior to inserting the first PTE, the race between add/revoke depends
upon struct_mutex for regular unmappings and rpm for runtime-suspend.

Signed-off-by: Chris Wilson 
Reviewed-by: Daniel Vetter  #v1
---
 drivers/gpu/drm/i915/i915_debugfs.c   |  2 +-
 drivers/gpu/drm/i915/i915_drv.h   | 20 +++--
 drivers/gpu/drm/i915/i915_gem.c   | 42 +++
 drivers/gpu/drm/i915/i915_gem_evict.c |  2 +-
 drivers/gpu/drm/i915/i915_gem_fence.c |  2 +-
 5 files changed, 49 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 20638d22bbad..1b402eebd3d9 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -107,7 +107,7 @@ static char get_tiling_flag(struct drm_i915_gem_object *obj)
 
 static char get_global_flag(struct drm_i915_gem_object *obj)
 {
-   return obj->fault_mappable ? 'g' : ' ';
+   return !list_empty(>userfault_link) ? 'g' : ' ';
 }
 
 static char get_pin_mapped_flag(struct drm_i915_gem_object *obj)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b339c916f7a9..60a3d879840a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1360,6 +1360,14 @@ struct i915_gem_mm {
 */
struct list_head unbound_list;
 
+   /** Protects access to the userfault_list */
+   spinlock_t userfault_lock;
+
+   /** List of all objects in gtt_space, currently mmaped by userspace.
+* All objects within this list must also be on bound_list.
+*/
+   struct list_head userfault_list;
+
/** Usable portion of the GTT for GEM */
unsigned long stolen_base; /* limited to low memory (32-bit) */
 
@@ -2204,6 +2212,11 @@ struct drm_i915_gem_object {
struct drm_mm_node *stolen;
struct list_head global_list;
 
+   /**
+* Whether the object is currently in the GGTT mmap.
+*/
+   struct list_head userfault_link;
+
/** Used in execbuf to temporarily hold a ref */
struct list_head obj_exec_link;
 
@@ -2231,13 +2244,6 @@ struct drm_i915_gem_object {
 */
unsigned int madv:2;
 
-   /**
-* Whether the current gtt mapping needs to be mappable (and isn't just
-* mappable by accident). Track pin and fault separate for a more
-* accurate mappable working set.
-*/
-   unsigned int fault_mappable:1;
-
/*
 * Is the object to be mapped as read-only to the GPU
 * Only honoured if hardware has relevant pte bit
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8ed8e24025ac..b7a6bcd15bc9 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1839,16 +1839,19 @@ int i915_gem_fault(struct vm_area_struct *area, struct 
vm_fault *vmf)
if (ret)
goto err_unpin;
 
+   /* Mark as being mmapped into userspace for later revocation */
+   spin_lock(_priv->mm.userfault_lock);
+   if (list_empty(>userfault_link))
+   list_add(>userfault_link, _priv->mm.userfault_list);
+   spin_unlock(_priv->mm.userfault_lock);
+
/* Finally, remap it using the new GTT offset */
ret = remap_io_mapping(area,
   area->vm_start + 
(vma->ggtt_view.params.partial.offset << PAGE_SHIFT),
   (ggtt->mappable_base + vma->node.start) >> 
PAGE_SHIFT,
   min_t(u64, vma->size, area->vm_end - 
area->vm_start),
   >mappable);
-   if (ret)
-   goto err_unpin;
 
-   obj->fault_mappable = true;
 err_unpin:
__i915_vma_unpin(vma);
 err_unlock:
@@ -1916,13 +1919,22 @@ int i915_gem_fault(struct vm_area_struct *area, struct 
vm_fault *vmf)
 void
 i915_gem_release_mmap(struct drm_i915_gem_object *obj)
 {
+   struct drm_i915_private *i915 = to_i915(obj->base.dev);
+   bool zap = false;
+
/* Serialisation between user GTT access and our code depends upon
 * revoking the CPU's PTE whilst the mutex is held. The next user
 * pagefault then has to wait until we release the mutex.
 */
-   lockdep_assert_held(>base.dev->struct_mutex);
+   lockdep_assert_held(>drm.struct_mutex);
 
-   if 

[Intel-gfx] [PATCH 3/5] drm/i915: Remove superfluous locking around userfault_list

[Chris Wilson]

Now that we have reduced the access to the list to either (a) under the
struct_mutex whilst holding the RPM wakeref (so that concurrent writers to
the list are serialised by struct_mutex) and (b) under the atomic
runtime suspend (which cannot run concurrently with any other accessor due
to the atomic nature of the runtime suspend) we can remove the extra
locking around the list itself.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_drv.h |  3 ---
 drivers/gpu/drm/i915/i915_gem.c | 33 -
 2 files changed, 12 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 60a3d879840a..c083ed37572b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1360,9 +1360,6 @@ struct i915_gem_mm {
 */
struct list_head unbound_list;
 
-   /** Protects access to the userfault_list */
-   spinlock_t userfault_lock;
-
/** List of all objects in gtt_space, currently mmaped by userspace.
 * All objects within this list must also be on bound_list.
 */
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 744939f652fc..64a88ce4b3c6 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1842,10 +1842,8 @@ int i915_gem_fault(struct vm_area_struct *area, struct 
vm_fault *vmf)
 
/* Mark as being mmapped into userspace for later revocation */
assert_rpm_wakelock_held(dev_priv);
-   spin_lock(_priv->mm.userfault_lock);
if (list_empty(>userfault_link))
list_add(>userfault_link, _priv->mm.userfault_list);
-   spin_unlock(_priv->mm.userfault_lock);
 
/* Finally, remap it using the new GTT offset */
ret = remap_io_mapping(area,
@@ -1922,7 +1920,6 @@ void
 i915_gem_release_mmap(struct drm_i915_gem_object *obj)
 {
struct drm_i915_private *i915 = to_i915(obj->base.dev);
-   bool zap = false;
 
/* Serialisation between user GTT access and our code depends upon
 * revoking the CPU's PTE whilst the mutex is held. The next user
@@ -1935,15 +1932,10 @@ i915_gem_release_mmap(struct drm_i915_gem_object *obj)
lockdep_assert_held(>drm.struct_mutex);
intel_runtime_pm_get(i915);
 
-   spin_lock(>mm.userfault_lock);
-   if (!list_empty(>userfault_link)) {
-   list_del_init(>userfault_link);
-   zap = true;
-   }
-   spin_unlock(>mm.userfault_lock);
-   if (!zap)
+   if (list_empty(>userfault_link))
goto out;
 
+   list_del_init(>userfault_link);
drm_vma_node_unmap(>base.vma_node,
   obj->base.dev->anon_inode->i_mapping);
 
@@ -1963,21 +1955,21 @@ i915_gem_release_mmap(struct drm_i915_gem_object *obj)
 void
 i915_gem_release_all_mmaps(struct drm_i915_private *dev_priv)
 {
-   struct drm_i915_gem_object *obj;
+   struct drm_i915_gem_object *obj, *on;
 
-   spin_lock(_priv->mm.userfault_lock);
-   while ((obj = list_first_entry_or_null(_priv->mm.userfault_list,
-  struct drm_i915_gem_object,
-  userfault_link))) {
-   list_del_init(>userfault_link);
-   spin_unlock(_priv->mm.userfault_lock);
+   /*
+* Only called during RPM suspend. All users of the userfault_list
+* must be holding an RPM wakeref to ensure that this can not
+* run concurrently with themselves (and use the struct_mutex for
+* protection between themselves).
+*/
 
+   list_for_each_entry_safe(obj, on,
+_priv->mm.userfault_list, userfault_link) {
+   list_del_init(>userfault_link);
drm_vma_node_unmap(>base.vma_node,
   obj->base.dev->anon_inode->i_mapping);
-
-   spin_lock(_priv->mm.userfault_lock);
}
-   spin_unlock(_priv->mm.userfault_lock);
 }
 
 /**
@@ -4547,7 +4539,6 @@ int i915_gem_init(struct drm_device *dev)
int ret;
 
mutex_lock(>struct_mutex);
-   spin_lock_init(_priv->mm.userfault_lock);
 
if (!i915.enable_execlists) {
dev_priv->gt.resume = intel_legacy_submission_resume;
-- 
2.9.3

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

Re: [Intel-gfx] [PATCH 5/7] drm/i915: Update kerneldoc for intel_dpll_mgr.c

[Daniel Vetter]

On Thu, Oct 20, 2016 at 11:56:07AM +0300, Ander Conselvan De Oliveira wrote:
> On Thu, 2016-10-20 at 11:19 +0300, Jani Nikula wrote:
> > On Thu, 20 Oct 2016, Daniel Vetter  wrote:
> > > 
> > > On Wed, Oct 19, 2016 at 06:29:13PM +0300, Jani Nikula wrote:
> > > > 
> > > > On Wed, 19 Oct 2016, Ander Conselvan De Oliveira 
> > > > wrote:
> > > > > 
> > > > > On Thu, 2016-10-13 at 15:46 +0200, Daniel Vetter wrote:
> > > > > > 
> > > > > > > 
> > > > > > > + /**
> > > > > > > +  * @hw_state: hardware configuration for the DPLL.
> > > > > > "... stored in struct _dpll_hw_state." - I love my hyperlinks 
> > > > > > ;-
> > > > > > )
> > > > > I'll add that, but I think it's silly. The type of the field is struct
> > > > > intel_dpll_hw_state, so I think it would be more natural if the
> > > > > documentation
> > > > > tool would add that link automatically.
> > > > Agreed.
> > > Someone volunteering? I'd hope it would be at most a bit of shuffling with
> > > the generator, we should have the type and all that handy already. Except
> > > maybe lots of corner-cases ...
> > I think the problem was that I couldn't figure out how to make Sphinx do
> > cross references within inline preformatted text. And I thought that was
> > less important than fixing up the struct presentation that I'm not all
> > too happy about currently. See [1] first. I don't think we need to have
> > both the definition and members. It's just wasted vertical space.
> > 
> > I'd suggest we drop the definition altogether, and have the members list
> > contain the member types, ideally with cross-references. If that means
> > having to use normal font instead of monospace, I'd go with it anyway.
> > 
> > Thoughts?
> 
> I think that makes sense. There's no extra information there (and if you 
> forget
> to add a kerneldoc tag to a field, it isn't even listed). The definition is in
> the code anyway.
> 
> I was actually a bit surprised to see the definition in the doc the first 
> time.

Assuming we're talking just about structs here: +1. For functions we
already have the signature in the heading, and that also already
hyperlinks.

There's also the difference that the detailed list has the full type+name,
whereas structs only have the name. I like the style used in functions
much more (and then we could just nuke the definition I think), and then
hyperlink them properly.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t v4] tests/kms_plane_multiple: CRC based atomic correctness test

[Mika Kahola]

This is a testcase with multiple planes. The idea here is the following

 - draw a uniform frame with blue color
 - grab crc for reference
 - put planes randomly on top with the same blue color
 - punch holes with black color into the primary framebuffer
 - ideally the planes should cover these holes so that the output is the
   identical to reference crc
 - composite all with one ioctl call
 - grab crc and verify that the reference crc is equal
 - repeat this for dozen iterations to maximize coverage

v4: For atomic test enable crc capturing before entering into a
iteration loop. After each iteration, check that page flip
didn't take no more than 1 vblank, fetch all crc's and check
the values.

Introduce new command line parameter for the number of iterations.
The test run from 1 to 256 iterations.

v3: Cleanup by removing separate plane array
For atomic, pass DRM_MODE_PAGE_FLIP_EVENT
Grab crc by using igt_pipe_crc_get_crc instead of igt_pipe_crc_collect_crc
Rename nplanes variable to max_planes
To optimize test execution, run iterations after the modeset

v2: Keep a logfile on random number seeds per subtest that are not skipped
due to unmet test requirements

Signed-off-by: Mika Kahola 
---
 tests/Makefile.sources |   1 +
 tests/kms_plane_multiple.c | 475 +
 2 files changed, 476 insertions(+)
 create mode 100644 tests/kms_plane_multiple.c

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 6d081c3..ffd59c1 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -105,6 +105,7 @@ TESTS_progs_M = \
kms_pipe_color \
kms_pipe_crc_basic \
kms_plane \
+   kms_plane_multiple \
kms_properties \
kms_psr_sink_crc \
kms_render \
diff --git a/tests/kms_plane_multiple.c b/tests/kms_plane_multiple.c
new file mode 100644
index 000..a18cdff
--- /dev/null
+++ b/tests/kms_plane_multiple.c
@@ -0,0 +1,475 @@
+/*
+ * Copyright © 2016 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include "igt.h"
+#include "drmtest.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+
+IGT_TEST_DESCRIPTION("Test atomic mode setting with multiple planes ");
+
+#define MAX_CRCS 1
+#define SIZE 128
+
+#define IN_RANGE(X, MIN, MAX) ((X) < (MIN) || (X) > (MAX) ? 16 : X)
+
+typedef struct {
+   float red;
+   float green;
+   float blue;
+} color_t;
+
+typedef struct {
+   int drm_fd;
+   igt_display_t display;
+   igt_pipe_crc_t *pipe_crc;
+   igt_plane_t *plane[IGT_MAX_PLANES];
+   struct igt_fb fb[IGT_MAX_PLANES];
+} data_t;
+
+typedef struct {
+   data_t *data;
+   igt_crc_t reference_crc;
+} test_position_t;
+
+/* Command line parameters. */
+struct {
+   unsigned iterations;
+   bool user_seed;
+   int seed;
+   bool user_logfile;
+   char logfile[SIZE];
+} opt = {
+   .iterations = 16,
+   .user_seed = false,
+   .seed = 1,
+   .user_logfile = false,
+   .logfile = "kms_plane_multiple.log",
+};
+
+static inline uint32_t pipe_select(int pipe)
+{
+   if (pipe > 1)
+   return pipe << DRM_VBLANK_HIGH_CRTC_SHIFT;
+   else if (pipe > 0)
+   return DRM_VBLANK_SECONDARY;
+   else
+   return 0;
+}
+
+static unsigned get_vblank(int fd, int pipe, unsigned flags)
+{
+   union drm_wait_vblank vbl;
+
+   memset(, 0, sizeof(vbl));
+   vbl.request.type = DRM_VBLANK_RELATIVE | pipe_select(pipe) | flags;
+   if (drmIoctl(fd, DRM_IOCTL_WAIT_VBLANK, ))
+   return 0;
+
+   return vbl.reply.sequence;
+}
+
+static int logwrite(const char *testname)
+{
+   time_t curr_time;
+   FILE *fid;
+   char *time_str;
+
+   fid = fopen(opt.logfile, "a");
+
+   if (fid == NULL) {
+   

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/dp: add lane_count check in intel_dp_check_link_status (rev2)

[Matthew Auld]

On 19 October 2016 at 22:47, Patchwork  wrote:
> == Series Details ==
>
> Series: drm/i915/dp: add lane_count check in intel_dp_check_link_status (rev2)
> URL   : https://patchwork.freedesktop.org/series/11667/
> State : warning
>
> == Summary ==
>
> Series 11667v2 drm/i915/dp: add lane_count check in intel_dp_check_link_status
> https://patchwork.freedesktop.org/api/1.0/series/11667/revisions/2/mbox/
>
> Test drv_module_reload_basic:
> pass   -> DMESG-WARN (fi-skl-6700hq)
[   36.849247] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
[   36.849278] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed on port B
[   36.867178] [Firmware Bug]: ACPI(PEGP) defines _DOD but not _DOS
[   38.946464] Setting dangerous option inject_load_failure - tainting kernel
[   39.093675] Setting dangerous option inject_load_failure - tainting kernel
[   39.258529] Setting dangerous option inject_load_failure - tainting kernel
[   39.424800] Setting dangerous option inject_load_failure - tainting kernel
[   40.497909] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
[   40.498321] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed on port B
[   40.530092] [Firmware Bug]: ACPI(PEGP) defines _DOD but not _DOS

Created bug report https://bugs.freedesktop.org/show_bug.cgi?id=98353

> Test gem_exec_suspend:
> Subgroup basic-s3:
> dmesg-warn -> PASS   (fi-skl-6700hq)
> Test kms_pipe_crc_basic:
> Subgroup nonblocking-crc-pipe-a:
> dmesg-warn -> PASS   (fi-ilk-650)
> Subgroup nonblocking-crc-pipe-b:
> pass   -> DMESG-WARN (fi-ivb-3770)
[  391.061781] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
invalid, remainder is 130
[  391.062331] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
invalid, remainder is 130

https://bugs.freedesktop.org/show_bug.cgi?id=98228
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] i915 and GTV-g maintenance, workflows and CI

[Zhenyu Wang]

On 2016.10.20 11:24:21 +0200, Daniel Vetter wrote:
> On Thu, Oct 20, 2016 at 12:02:54PM +0300, Jani Nikula wrote:
> > 
> > We need to formalize the process between i915 proper and GVT-g a bit
> > more, and address some of the current shortcomings and issues in the
> > process and GVT-g CI.
> > 
> > This started off internally as a random list of items, I'm including
> > some of the current status as well. Please comment, as some of the stuff
> > here are just my opinions.
> > 
> > * How do we ensure GVT-g patches get the same kind of pre-merge CI
> >   coverage as we have for other i915 code? Could we at least make CI run
> >   tests on GVT-g pull requests before merging to drm-intel trees?
> > 
> >   => Work in progress to set up GVT-g CI.
> 
> Personally I don't think gvt needs to pass drm-intel CI. If GVT folks want
> to do that then it's fine, but otherwise I'm leaning towards treating gvt
> like a sub-driver, with its own flavour of testing and review standards.
>

Normally GVT-g shouldn't impact drm-intel CI. I do like to setup GVT-g specific
CI with fancy multiple VMs auto test available. But it might need some time
for QA team to setup that way.

> Of course anything touching shared code (i.e. outside of the gvt/ subdir),
> or code which can't be disabled with Kconfig needs to follow our
> established review procedures. So submission to intel-gfx, CI by
> patchwork, review per our standards.
> 
> > * How do we handle fixes to GVT-g code? Do all fixes need to go via the
> >   GVT-g mailing lists and review? We're bound to get GVT-g patches on
> >   intel-gfx mailing list too. There's confusion already [1]. Mostly the
> >   GVT-g changes come from GVT-g maintainers as pull requests.
> > 
> >   [1] https://patchwork.freedesktop.org/series/14000/
> 
> Atm the gvt mailing list is closed, and there's no maintainer entry for it
> either. I think Zhenyu just needs to hang out here on intel-gfx to catch
> these, and then pick any gvt/ fixes up himself.
>

We're working with 01.org admin to fix that ASAP. I didn't realize
01.org list has such issue, just thought we have aligned user/dev
igvt-g list on same place, otherwise I'd have considered other way..
But yes, we will still include intel-gfx list in maintainer file and
keep eye on it.

> > * GVT-g related changes to i915 proper must be reviewed on intel-gfx
> >   mailing list, and must either be applied to drm-intel directly, or get
> >   an ack to be merged via GVT-g tree and pull requests.
> 
> Ack.

Agreed.

> 
> > * GVT-g needs to start annotating fixes with the Fixes: tags, preferably
> >   also cc: stable when we get that far, so our fixes plumbing can figure
> >   out which commits to backport.
> > 
> >   => GVT-g maintainers will take care of this.
> 
> Either that, or they need to send -fixes pull requests your way. I think
> we could try out either approach, but yes in the end gvt maintainers need
> to own this. We (i915 team here) won't take care of that.
>

yeah, I think we should follow that way.

> > * Should GVT-g have a MAINTAINERS entry of its own?
> > 
> >   => 
> > https://github.com/01org/gvt-linux/commit/41161c9e9e50a5bad98a0e74ad0878c352bdea40
> > 
> > +INTEL GVT-g DRIVERS (Intel GPU Virtualization)
> > +M:  Zhenyu Wang 
> > +M:  Zhi Wang 
> > +L:  igvt-g-...@lists.01.org
> 
> Need to make sure igvt-g-dev is open to non-subscribers first. Otherwise
> ack.

fixing...

> 
> > +L:  intel-gfx@lists.freedesktop.org
> > +W:  https://01.org/igvt-g
> > +T:  git https://github.com/01org/gvt-linux.git
> > +S:  Supported
> > +F:  drivers/gpu/drm/i915/gvt/
> > 
> >   I think we'll want to keep intel-gfx there, but mostly I think it's
> >   fine for the usual GVT-g development to happen on igvt-g-dev only.
> 
> +1
> 
> > * igvt-g-...@lists.01.org needs to start accepting mails from
> >   non-subscribers.
> > 
> >   => Work in progress.
> 
> Definitely ;-)
> 
> > * GVT-g needs to start paying more attention to compiler and sparse
> >   warnings.
> > 
> >   => GVT-G maintainers will take care of this.
> > 
> > * GVT-g could use some overview documentation under Documentation/gpu.
> 
> Hm, should we have a TODO file in gvt for some of the issues raised? Otoh
> most things are fairly small issues, so should all be fixable before 4.10
> freeze.

Next big merge will be integration work with VFIO/mdev framework. Both VFIO/mdev
and our GVT-g device model work are for 4.10. Currently we already have working
patch sets internally based on newest VFIO/mdev v9 series. We'd like to put
a topic branch this week to be reviewed by VFIO community to make sure 
everything
work as designed.

I think a TODO file might help us to track left issues, will consider that.

> 
> > * GVT-g bug management. Do you have something set up already? Would be
> >   great to be able to use https://bugs.freedesktop.org so we could
> >   reassign between i915 and GVT-g.

Re: [Intel-gfx] [PATCH igt] igt/drv_hangman: Use manual error-state generation

[Chris Wilson]

On Thu, Oct 20, 2016 at 11:29:05AM +0200, Daniel Vetter wrote:
> On Thu, Oct 20, 2016 at 10:07:39AM +0100, Chris Wilson wrote:
> > For the basic error state, we only desire that an error state be created
> > following a hang. For that purpose, we do not need a real hang (slow
> > 6-12s) but can inject one instead (fast <1s).
> > 
> > Signed-off-by: Chris Wilson 
> 
> Should we instead speed up hangcheck? I think there's lots of value in
> making sure not just error dumping, but also hang detection works somewhat
> in BAT. Since if it doesn't any attempt at a full run will lead to pretty
> serious disasters. And I have this dream that BAT is the gating thing
> deciding whether a patch series deserves a complete pre-merge run ;-)

We have full-hang detection in BAT elsewhere as well. This particular
test was only asking the question "do we generate an error state", hence
why I felt it was safe to just do that and skip a simulated hang.
 
> But since this is a controlled enviromnent we could make hangcheck
> super-fast at timing out with some debugfs knob. Would probably also help
> a lot with speeding up the gazillion of testcases in gem_reset_stats.

I have considered i915.hangcheck_interval_ms many a time. It is not just
the interval but the hangcheck score threshold to consider. If we can
trust our activity detection, we would be safe with a hangcheck every
jiffie (at some overhead mind you), but we would declare a dos too soon.
-Chris

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

Re: [Intel-gfx] [PATCH 07/12] drm/i915/gvt: Hold a reference on the request

[Zhenyu Wang]

On 2016.10.20 07:52:18 +0100, Chris Wilson wrote:
> On Thu, Oct 20, 2016 at 08:22:00AM +0800, Zhenyu Wang wrote:
> > On 2016.10.19 11:11:42 +0100, Chris Wilson wrote:
> > > The workload took a pointer to the request, and even waited upon,
> > > without holding a reference on the request. Take that reference
> > > explicitly and fix up the error path following request allocation that
> > > missed flushing the request.
> > > 
> > > Signed-off-by: Chris Wilson 
> > > ---
> > >  drivers/gpu/drm/i915/gvt/scheduler.c | 24 +---
> > >  1 file changed, 13 insertions(+), 11 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
> > > b/drivers/gpu/drm/i915/gvt/scheduler.c
> > > index b15cdf5978a9..224f19ae61ab 100644
> > > --- a/drivers/gpu/drm/i915/gvt/scheduler.c
> > > +++ b/drivers/gpu/drm/i915/gvt/scheduler.c
> > > @@ -163,6 +163,7 @@ static int dispatch_workload(struct 
> > > intel_vgpu_workload *workload)
> > >   int ring_id = workload->ring_id;
> > >   struct i915_gem_context *shadow_ctx = workload->vgpu->shadow_ctx;
> > >   struct drm_i915_private *dev_priv = workload->vgpu->gvt->dev_priv;
> > > + struct drm_i915_gem_request *rq;
> > >   int ret;
> > >  
> > >   gvt_dbg_sched("ring id %d prepare to dispatch workload %p\n",
> > > @@ -171,17 +172,16 @@ static int dispatch_workload(struct 
> > > intel_vgpu_workload *workload)
> > >   shadow_ctx->desc_template = workload->ctx_desc.addressing_mode <<
> > >   GEN8_CTX_ADDRESSING_MODE_SHIFT;
> > >  
> > > - workload->req = i915_gem_request_alloc(dev_priv->engine[ring_id],
> > > -shadow_ctx);
> > > - if (IS_ERR_OR_NULL(workload->req)) {
> > > + rq = i915_gem_request_alloc(dev_priv->engine[ring_id], shadow_ctx);
> > > + if (IS_ERR(rq)) {
> > >   gvt_err("fail to allocate gem request\n");
> > > - workload->status = PTR_ERR(workload->req);
> > > - workload->req = NULL;
> > > + workload->status = PTR_ERR(rq);
> > >   return workload->status;
> > >   }
> > >  
> > > - gvt_dbg_sched("ring id %d get i915 gem request %p\n",
> > > - ring_id, workload->req);
> > > + gvt_dbg_sched("ring id %d get i915 gem request %p\n", ring_id, rq);
> > > +
> > > + workload->req = i915_gem_request_get(rq);
> > >  
> > >   mutex_lock(>lock);
> > >  
> > > @@ -208,16 +208,16 @@ static int dispatch_workload(struct 
> > > intel_vgpu_workload *workload)
> > >   gvt_dbg_sched("ring id %d submit workload to i915 %p\n",
> > >   ring_id, workload->req);
> > >  
> > > - i915_add_request_no_flush(workload->req);
> > > -
> > > + i915_add_request_no_flush(rq);
> > >   workload->dispatched = true;
> > >   return 0;
> > >  err:
> > >   workload->status = ret;
> > > - if (workload->req)
> > > - workload->req = NULL;
> > > + i915_gem_request_put(fetch_and_zero(>req));
> > >
> > 
> > Looks we don't need put here as in error path from dispatch_workload()
> > we will go with below put path too in main thread.
> 
> If we clear the request pointer, then we need the put. But yes, we don't
> necessarily need to clear the pointer on error for the caller, as the
> caller doesn't distinguish the error path and the no-op request can be
> handled identically to a real request.

Would you refresh this one? So I'd send out next pull request with this.

thanks

-- 
Open Source Technology Center, Intel ltd.

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


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

Re: [Intel-gfx] [PATCH RESEND 9/9] drm/i915: set proper N/M in modeset

[Yang, Libin]

> -Original Message-
> From: Nikula, Jani
> Sent: Thursday, October 20, 2016 4:34 PM
> To: Yang, Libin ; Lin, Mengdong
> ; intel-gfx@lists.freedesktop.org
> Cc: libin.y...@linux.intel.com; Pandiyan, Dhinakaran
> ; Zhang, Keqiao
> ; Zhao, Juan J 
> Subject: RE: [Intel-gfx] [PATCH RESEND 9/9] drm/i915: set proper N/M in
> modeset
> 
> On Thu, 20 Oct 2016, "Yang, Libin"  wrote:
> >> -Original Message-
> >> From: Nikula, Jani
> >> Sent: Wednesday, October 19, 2016 11:09 PM
> >> To: Yang, Libin ; Lin, Mengdong
> >> ; intel-gfx@lists.freedesktop.org
> >> Cc: libin.y...@linux.intel.com; Pandiyan, Dhinakaran
> >> ; Zhang, Keqiao
> >> ; Zhao, Juan J 
> >> Subject: RE: [Intel-gfx] [PATCH RESEND 9/9] drm/i915: set proper N/M
> >> in modeset
> >>
> >>
> >> Sorry it's taken me forever to get back to this. Some comments inline.
> >>
> >> BR,
> >> Jani.
> >>
> >> On Wed, 12 Oct 2016, "Yang, Libin"  wrote:
> >> >> -Original Message-
> >> >> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org]
> >> >> On Behalf Of Lin, Mengdong
> >> >> Sent: Wednesday, October 12, 2016 10:46 AM
> >> >> To: Nikula, Jani ;
> >> >> intel-gfx@lists.freedesktop.org
> >> >> Cc: Nikula, Jani ;
> >> >> libin.y...@linux.intel.com; Pandiyan, Dhinakaran
> >> >> 
> >> >> Subject: Re: [Intel-gfx] [PATCH RESEND 9/9] drm/i915: set proper
> >> >> N/M in modeset
> >> >>
> >> >>
> >> >>
> >> >> > -Original Message-
> >> >> > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org]
> >> >> > On Behalf Of Jani Nikula
> >> >> > Sent: Monday, October 10, 2016 11:04 PM
> >> >> > To: intel-gfx@lists.freedesktop.org
> >> >> > Cc: Nikula, Jani ;
> >> >> > libin.y...@linux.intel.com; Pandiyan, Dhinakaran
> >> >> > 
> >> >> > Subject: [Intel-gfx] [PATCH RESEND 9/9] drm/i915: set proper N/M
> >> >> > in modeset
> >> >> >
> >> >> > When modeset occurs and the LS_CLK is set to some special values
> >> >> > in DP mode, the N/M need to be set manually if audio is playing.
> >> >> > Otherwise the first several seconds may be silent in audio playback.
> >> >> >
> >> >> > The relationship of Maud and Naud is expressed in the following
> >> equation:
> >> >> > Maud/Naud = 512 * fs / f_LS_Clk
> >> >> >
> >> >> > Please refer VESA DisplayPort Standard spec for details.
> >> >> >
> >> >> > Signed-off-by: Libin Yang 
> >> >> > Signed-off-by: Jani Nikula 
> >> >> > ---
> >> >> >  drivers/gpu/drm/i915/i915_reg.h|   7 +++
> >> >> >  drivers/gpu/drm/i915/intel_audio.c | 100
> >> >> > -
> >> >> >  2 files changed, 105 insertions(+), 2 deletions(-)
> >> >> >
> >> >> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> >> >> > b/drivers/gpu/drm/i915/i915_reg.h index
> >> >> > 595d196f753f..8d9dbc7d5b32
> >> >> > 100644
> >> >> > --- a/drivers/gpu/drm/i915/i915_reg.h
> >> >> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> >> >> > @@ -7359,6 +7359,13 @@ enum {
> >> >> >  #define _HSW_AUD_MISC_CTRL_B 0x65110
> >> >> >  #define HSW_AUD_MISC_CTRL(pipe)  _MMIO_PIPE(pipe,
> >> >> > _HSW_AUD_MISC_CTRL_A, _HSW_AUD_MISC_CTRL_B)
> >> >> >
> >> >> > +#define _HSW_AUD_M_CTS_ENABLE_A  0x65028
> >> >> > +#define _HSW_AUD_M_CTS_ENABLE_B  0x65128
> >> >> > +#define HSW_AUD_M_CTS_ENABLE(pipe)   _MMIO_PIPE(pipe,
> >> >> > _HSW_AUD_M_CTS_ENABLE_A, _HSW_AUD_M_CTS_ENABLE_B)
> >> >> > +#define   AUD_M_CTS_M_VALUE_INDEX(1 << 21)
> >> >> > +#define   AUD_M_CTS_M_PROG_ENABLE(1 << 20)
> >> >> > +#define   AUD_CONFIG_M_MASK  0xf
> >> >>
> >> >> The last line cause misalignment after applying the patch.
> >> >>
> >> >> > +
> >> >> >  #define _HSW_AUD_DIP_ELD_CTRL_ST_A   0x650b4
> >> >> >  #define _HSW_AUD_DIP_ELD_CTRL_ST_B   0x651b4
> >> >> >  #define HSW_AUD_DIP_ELD_CTRL(pipe)   _MMIO_PIPE(pipe,
> >> >> > _HSW_AUD_DIP_ELD_CTRL_ST_A, _HSW_AUD_DIP_ELD_CTRL_ST_B)
> >> diff --
> >> >> git
> >> >> > a/drivers/gpu/drm/i915/intel_audio.c
> >> >> > b/drivers/gpu/drm/i915/intel_audio.c
> >> >> > index 81df29ca4947..0bc2701b6c9c 100644
> >> >> > --- a/drivers/gpu/drm/i915/intel_audio.c
> >> >> > +++ b/drivers/gpu/drm/i915/intel_audio.c
> >> >> > @@ -57,6 +57,70 @@
> >> >> >   * struct _audio_component_audio_ops @audio_ops is called
> >> >> > from
> >> >> > i915 driver.
> >> >> >   */
> >> >> >
> >> >> > +/* DP N/M table */
> >> >> > +#define LC_540M 54
> >> >> > +#define LC_270M 27
> >> >> > +#define LC_162M 162000
> >> >> > +
> >> >> > +struct dp_aud_n_m {
> >> >> > + int sample_rate;
> >> >> > + 

[Intel-gfx] ✗ Fi.CI.BAT: warning for Intel DRM Driver - Weathered Colours Patch

[Patchwork]

== Series Details ==

Series: Intel DRM Driver - Weathered Colours Patch
URL   : https://patchwork.freedesktop.org/series/14077/
State : warning

== Summary ==

Series 14077v1 Intel DRM Driver - Weathered Colours Patch
https://patchwork.freedesktop.org/api/1.0/series/14077/revisions/1/mbox/

Test drv_module_reload_basic:
dmesg-warn -> PASS   (fi-skl-6700hq)
Test gem_exec_suspend:
Subgroup basic-s3:
pass   -> DMESG-WARN (fi-skl-6700hq)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-skl-6700hq)
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-skl-6700hq)
Subgroup suspend-read-crc-pipe-c:
pass   -> DMESG-WARN (fi-skl-6700hq)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
fi-byt-n2820 total:246  pass:211  dwarn:0   dfail:0   fail:0   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-ilk-650   total:246  pass:185  dwarn:0   dfail:0   fail:1   skip:60 
fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:219  dwarn:4   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_2771/

0b12b48da3bc580102665ee9efd7e834f6def00f drm-intel-nightly: 
2016y-10m-20d-07h-52m-31s UTC integration manifest
ac4a8d0 Intel DRM Driver - Weathered Colours Patch

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

Re: [Intel-gfx] [PATCH igt] igt: drop gem_storedw_loop from BAT

[Chris Wilson]

On Thu, Oct 20, 2016 at 11:45:47AM +0300, Petri Latvala wrote:
> On Wed, Oct 19, 2016 at 08:26:17PM +0100, Chris Wilson wrote:
> > The inter-engine synchronisation (with and without semaphores) is
> > equally exercised by gem_sync, so leave gem_storedw_loop out of the
> > "quick" set.
> 
> 
> How equally is "equally"? Is the test actually redundant, should it be
> removed altogether?

The stress patterns exhibited by the test are identical to others in
BAT. The accuracy tests are covered by others in BAT. The actual flow
(edge coverage) will be subtly different and therefore the test is still
unique and may catch future bugs not caught by others. But as far as BAT
goes the likelihood of this catching something not caught by others
within BAT is very very small.
-Chris

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

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/5] drm/i915: Move user fault tracking to a separate list

[Patchwork]

== Series Details ==

Series: series starting with [1/5] drm/i915: Move user fault tracking to a 
separate list
URL   : https://patchwork.freedesktop.org/series/14080/
State : warning

== Summary ==

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

Test drv_module_reload_basic:
pass   -> DMESG-WARN (fi-skl-6770hq)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
fi-byt-n2820 total:246  pass:211  dwarn:0   dfail:0   fail:0   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-ilk-650   total:246  pass:185  dwarn:0   dfail:0   fail:1   skip:60 
fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:246  pass:231  dwarn:1   dfail:0   fail:0   skip:14 
fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_2772/

0b12b48da3bc580102665ee9efd7e834f6def00f drm-intel-nightly: 
2016y-10m-20d-07h-52m-31s UTC integration manifest
852c2c5 drm/i915: Move fence cancellation to runtime suspend
29f36a3 drm/i915: Remove RPM sequence checking
3b789c0b drm/i915: Remove superfluous locking around userfault_list
95c7dc2 drm/i915: Use RPM as the barrier for controlling user mmap access
72207d3 drm/i915: Move user fault tracking to a separate list

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

Re: [Intel-gfx] [PATCH igt] igt: drop gem_storedw_loop from BAT

[Daniel Vetter]

On Thu, Oct 20, 2016 at 09:54:33AM +0100, Chris Wilson wrote:
> On Thu, Oct 20, 2016 at 11:45:47AM +0300, Petri Latvala wrote:
> > On Wed, Oct 19, 2016 at 08:26:17PM +0100, Chris Wilson wrote:
> > > The inter-engine synchronisation (with and without semaphores) is
> > > equally exercised by gem_sync, so leave gem_storedw_loop out of the
> > > "quick" set.
> >
> >
> > How equally is "equally"? Is the test actually redundant, should it be
> > removed altogether?
>
> The stress patterns exhibited by the test are identical to others in
> BAT. The accuracy tests are covered by others in BAT. The actual flow
> (edge coverage) will be subtly different and therefore the test is still
> unique and may catch future bugs not caught by others. But as far as BAT
> goes the likelihood of this catching something not caught by others
> within BAT is very very small.

But given that we have 50k gem tests in full igt, does it really make
sense to keep it? Imo there's not much point in keeping around every
minute combinatorial variation if it means we can never run the full set
of testcases. Some serious trimming of the herd is probably called for.

Joonas/Tvrtko/Mika and other gem folks: What's your stance here?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] i915 and GTV-g maintenance, workflows and CI

[Daniel Vetter]

On Thu, Oct 20, 2016 at 12:02:54PM +0300, Jani Nikula wrote:
> 
> We need to formalize the process between i915 proper and GVT-g a bit
> more, and address some of the current shortcomings and issues in the
> process and GVT-g CI.
> 
> This started off internally as a random list of items, I'm including
> some of the current status as well. Please comment, as some of the stuff
> here are just my opinions.
> 
> * How do we ensure GVT-g patches get the same kind of pre-merge CI
>   coverage as we have for other i915 code? Could we at least make CI run
>   tests on GVT-g pull requests before merging to drm-intel trees?
> 
>   => Work in progress to set up GVT-g CI.

Personally I don't think gvt needs to pass drm-intel CI. If GVT folks want
to do that then it's fine, but otherwise I'm leaning towards treating gvt
like a sub-driver, with its own flavour of testing and review standards.

Of course anything touching shared code (i.e. outside of the gvt/ subdir),
or code which can't be disabled with Kconfig needs to follow our
established review procedures. So submission to intel-gfx, CI by
patchwork, review per our standards.

> * How do we handle fixes to GVT-g code? Do all fixes need to go via the
>   GVT-g mailing lists and review? We're bound to get GVT-g patches on
>   intel-gfx mailing list too. There's confusion already [1]. Mostly the
>   GVT-g changes come from GVT-g maintainers as pull requests.
> 
>   [1] https://patchwork.freedesktop.org/series/14000/

Atm the gvt mailing list is closed, and there's no maintainer entry for it
either. I think Zhenyu just needs to hang out here on intel-gfx to catch
these, and then pick any gvt/ fixes up himself.

> * GVT-g related changes to i915 proper must be reviewed on intel-gfx
>   mailing list, and must either be applied to drm-intel directly, or get
>   an ack to be merged via GVT-g tree and pull requests.

Ack.

> * GVT-g needs to start annotating fixes with the Fixes: tags, preferably
>   also cc: stable when we get that far, so our fixes plumbing can figure
>   out which commits to backport.
> 
>   => GVT-g maintainers will take care of this.

Either that, or they need to send -fixes pull requests your way. I think
we could try out either approach, but yes in the end gvt maintainers need
to own this. We (i915 team here) won't take care of that.

> * Should GVT-g have a MAINTAINERS entry of its own?
> 
>   => 
> https://github.com/01org/gvt-linux/commit/41161c9e9e50a5bad98a0e74ad0878c352bdea40
> 
>   +INTEL GVT-g DRIVERS (Intel GPU Virtualization)
>   +M:  Zhenyu Wang 
>   +M:  Zhi Wang 
>   +L:  igvt-g-...@lists.01.org

Need to make sure igvt-g-dev is open to non-subscribers first. Otherwise
ack.

>   +L:  intel-gfx@lists.freedesktop.org
>   +W:  https://01.org/igvt-g
>   +T:  git https://github.com/01org/gvt-linux.git
>   +S:  Supported
>   +F:  drivers/gpu/drm/i915/gvt/
> 
>   I think we'll want to keep intel-gfx there, but mostly I think it's
>   fine for the usual GVT-g development to happen on igvt-g-dev only.

+1

> * igvt-g-...@lists.01.org needs to start accepting mails from
>   non-subscribers.
> 
>   => Work in progress.

Definitely ;-)

> * GVT-g needs to start paying more attention to compiler and sparse
>   warnings.
> 
>   => GVT-G maintainers will take care of this.
> 
> * GVT-g could use some overview documentation under Documentation/gpu.

Hm, should we have a TODO file in gvt for some of the issues raised? Otoh
most things are fairly small issues, so should all be fixable before 4.10
freeze.

> * GVT-g bug management. Do you have something set up already? Would be
>   great to be able to use https://bugs.freedesktop.org so we could
>   reassign between i915 and GVT-g.

+1.

> What did I forget/overlook?

Nothing else crosses my mind, but I'm sure we'll discover more ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH igt] igt: drop gem_storedw_loop from BAT

[Tvrtko Ursulin]

On 20/10/2016 15:02, Chris Wilson wrote:

On Thu, Oct 20, 2016 at 02:55:42PM +0100, Tvrtko Ursulin wrote:

On 20/10/2016 10:16, Daniel Vetter wrote:

On Thu, Oct 20, 2016 at 09:54:33AM +0100, Chris Wilson wrote:

On Thu, Oct 20, 2016 at 11:45:47AM +0300, Petri Latvala wrote:

On Wed, Oct 19, 2016 at 08:26:17PM +0100, Chris Wilson wrote:

The inter-engine synchronisation (with and without semaphores) is
equally exercised by gem_sync, so leave gem_storedw_loop out of the
"quick" set.

How equally is "equally"? Is the test actually redundant, should it be
removed altogether?

The stress patterns exhibited by the test are identical to others in
BAT. The accuracy tests are covered by others in BAT. The actual flow
(edge coverage) will be subtly different and therefore the test is still
unique and may catch future bugs not caught by others. But as far as BAT
goes the likelihood of this catching something not caught by others
within BAT is very very small.

But given that we have 50k gem tests in full igt, does it really make
sense to keep it? Imo there's not much point in keeping around every
minute combinatorial variation if it means we can never run the full set
of testcases. Some serious trimming of the herd is probably called for.

Joonas/Tvrtko/Mika and other gem folks: What's your stance here?

I am very fond of gem_storedw_loop, it was indispensable during
platform bringup in Fulsim in a not so distant past.

Even if not so, it is a very short and simple test ("Basic CS check
using MI_STORE_DATA_IMM"), while gem_sync is much more complex and
deals with a different issues.

See gem_exec_store for an even shorter sanity test of CS (also in BAT).
We have overlap between this, gem_exec_basic, gem_exec_store,
gem_exec_nop, gem_ringfill and gem_sync.


Without going into wider discussion, I vote to keep this particular test.

In BAT?


No sorry I read some later bits of the thread and came back to reply 
here - I was referring just to the igt codebase.


Regards,

Tvrtko



-Chris



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

[Intel-gfx] [PATCH 1/4] MAINTAINERS: Add "B:" for URI where to file bugs

[Jani Nikula]

Different subsystems and drivers have different preferences for where to
file bugs and what information to include. Add "B:" entry for specifying
the URI for the bug tracker directly, a web page for detailed info on
filing bugs, or a mailto: URI.

Cc: Daniel Vetter 
Cc: Joe Perches 
Cc: Andrew Morton 
Signed-off-by: Jani Nikula 

---

Dust settled since the last time, maybe we can make URI work?
---
 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 89112a65b831..4a47ec00a09d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -74,6 +74,8 @@ Descriptions of section entries:
   These reviewers should be CCed on patches.
L: Mailing list that is relevant to this area
W: Web-page with status/info
+   B: URI for where to file bugs. A web-page with detailed bug
+  filing info, a direct bug tracker link, or a mailto: URI.
Q: Patchwork web based patch tracking system site
T: SCM tree type and location.
   Type is one of: git, hg, quilt, stgit, topgit
-- 
2.1.4

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

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/4] MAINTAINERS: Add "B:" for URI where to file bugs

[Patchwork]

== Series Details ==

Series: series starting with [1/4] MAINTAINERS: Add "B:" for URI where to file 
bugs
URL   : https://patchwork.freedesktop.org/series/14106/
State : warning

== Summary ==

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

Test drv_module_reload_basic:
pass   -> DMESG-WARN (fi-skl-6770hq)
pass   -> DMESG-WARN (fi-skl-6700hq)
Test gem_exec_suspend:
Subgroup basic-s3:
dmesg-warn -> PASS   (fi-skl-6700hq)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-skl-6700hq)
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-skl-6700hq)
Subgroup suspend-read-crc-pipe-c:
dmesg-warn -> PASS   (fi-skl-6700hq)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
fi-byt-n2820 total:246  pass:211  dwarn:0   dfail:0   fail:0   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-ilk-650   total:246  pass:185  dwarn:0   dfail:0   fail:1   skip:60 
fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:246  pass:231  dwarn:1   dfail:0   fail:0   skip:14 
fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_2776/

908632bd31141332e8fabea8b452c27c122da6a6 drm-intel-nightly: 
2016y-10m-20d-12h-00m-29s UTC integration manifest
a717ceb MAINTAINERS: add drm and drm/i915 irc channels
96f4724 MAINTAINERS: Add "C:" for URI for chat where developers hang out
557b2fb MAINTAINERS: add drm and drm/i915 bug filing info
c550701 MAINTAINERS: Add "B:" for URI where to file bugs

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

Re: [Intel-gfx] i915 monitor hotplug on 4.1/4.4 PREEMPT

[David Weinehall]

On Thu, Oct 20, 2016 at 03:28:10PM +0300, Jani Nikula wrote:
> On Thu, 20 Oct 2016, Nicolae Rosia  wrote:
> > Monitor hotplugging seems to be broken on latest 4.1/4.4 RT kernel with 
> > i915.
> > I have tested this on non-RT kernel and it works.

The answer to your first question seems to be here :)

> > I get an udev event for unplugging, but there's no event generated for
> > plugging the monitor back in.
> 
> Does it work on non-RT? Does it work on v4.8 or v4.9-rc1?

The second one is relevant though. 4.1 is pre-historic, 4.4 is ancient.


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

Re: [Intel-gfx] [PATCH] drm: Complete CEA modedb(VIC 1-107)

[Jose Abreu]

Hi Shashank,


On 20-10-2016 11:25, Sharma, Shashank wrote:
> Adding Jose and Daniel in cc. 
>
> Regards
> Shashank 
> -Original Message-
> From: Sharma, Shashank 
> Sent: Thursday, October 20, 2016 3:58 PM
> To: dri-de...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org
> Cc: airl...@redhat.com; =daniel.vet...@intel.com; jose.ab...@synopsys.com; 
> Sharma, Shashank ; Joes Abreu 
> 
> Subject: [PATCH] drm: Complete CEA modedb(VIC 1-107)
>
> CEA-861-F specs defines new 4k video modes to be used with HDMI 2.0 EDIDs. 
> These modes start at VIC=93 and go all the way till VIC=107.
>
> Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now to be 
> able to parse 4k modes using the existing techniques, we have to complete the 
> modedb (VIC=65 onwards).
>
> This patch adds:
> - Timings for existing CEA video modes (from VIC=65 till VIC=92)
> - Newly added 4k modes (from VIC=93 to VIC=107).
>
> Signed-off-by: Shashank Sharma 
> Signed-off-by: Sonika Jindal 
>
> Cc: Joes Abreu 

It's Jose (jose.ab...@synopsys.com), not Joes, please.

> ---
>  drivers/gpu/drm/drm_edid.c | 231 
> +
>  1 file changed, 231 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 
> 95de47b..0b97a1b 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -994,6 +994,237 @@ struct minimode {
>  2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
>  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
>.vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> + /* 65 - 1280x720@24Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 59400, 1280, 3040,
> +3080, 3300, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 66 - 1280x720@25Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3700,
> +3740, 3960, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 67 - 1280x720@30Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 3040,
> +3080, 3300, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 68 - 1280x720@50Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1720,
> +1760, 1980, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 69 - 1280x720@60Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1390,
> +1430, 1650, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 70 - 1280x720@100Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1720,
> +1760, 1980, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 71 - 1280x720@120Hz */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 148500, 1280, 1390,
> +1430, 1650, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 120, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 72 - 1920x1080@24Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2558,
> +2602, 2750, 0, 1080, 1084, 1089, 1125, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 73 - 1920x1080@25Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2448,
> +2492, 2640, 0, 1080, 1084, 1089, 1125, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 74 - 1920x1080@30Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2008,
> +2052, 2200, 0, 1080, 1084, 1089, 1125, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
> + /* 75 - 1920x1080@50Hz */
> + { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 148500, 1920, 2448,
> +2492, 2640, 0, 1080, 1084, 

Re: [Intel-gfx] [PATCH igt] igt: drop gem_storedw_loop from BAT

[Tvrtko Ursulin]

On 20/10/2016 10:16, Daniel Vetter wrote:

On Thu, Oct 20, 2016 at 09:54:33AM +0100, Chris Wilson wrote:

On Thu, Oct 20, 2016 at 11:45:47AM +0300, Petri Latvala wrote:

On Wed, Oct 19, 2016 at 08:26:17PM +0100, Chris Wilson wrote:

The inter-engine synchronisation (with and without semaphores) is
equally exercised by gem_sync, so leave gem_storedw_loop out of the
"quick" set.


How equally is "equally"? Is the test actually redundant, should it be
removed altogether?

The stress patterns exhibited by the test are identical to others in
BAT. The accuracy tests are covered by others in BAT. The actual flow
(edge coverage) will be subtly different and therefore the test is still
unique and may catch future bugs not caught by others. But as far as BAT
goes the likelihood of this catching something not caught by others
within BAT is very very small.

But given that we have 50k gem tests in full igt, does it really make
sense to keep it? Imo there's not much point in keeping around every
minute combinatorial variation if it means we can never run the full set
of testcases. Some serious trimming of the herd is probably called for.

Joonas/Tvrtko/Mika and other gem folks: What's your stance here?


I am very fond of gem_storedw_loop, it was indispensable during platform 
bringup in Fulsim in a not so distant past.


Even if not so, it is a very short and simple test ("Basic CS check 
using MI_STORE_DATA_IMM"), while gem_sync is much more complex and deals 
with a different issues.


Without going into wider discussion, I vote to keep this particular test.

Regards,

Tvrtko

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

Re: [Intel-gfx] [PATCH igt] igt: drop gem_storedw_loop from BAT

[Chris Wilson]

On Thu, Oct 20, 2016 at 02:55:42PM +0100, Tvrtko Ursulin wrote:
> 
> On 20/10/2016 10:16, Daniel Vetter wrote:
> >On Thu, Oct 20, 2016 at 09:54:33AM +0100, Chris Wilson wrote:
> >>On Thu, Oct 20, 2016 at 11:45:47AM +0300, Petri Latvala wrote:
> >>>On Wed, Oct 19, 2016 at 08:26:17PM +0100, Chris Wilson wrote:
> The inter-engine synchronisation (with and without semaphores) is
> equally exercised by gem_sync, so leave gem_storedw_loop out of the
> "quick" set.
> >>>
> >>>How equally is "equally"? Is the test actually redundant, should it be
> >>>removed altogether?
> >>The stress patterns exhibited by the test are identical to others in
> >>BAT. The accuracy tests are covered by others in BAT. The actual flow
> >>(edge coverage) will be subtly different and therefore the test is still
> >>unique and may catch future bugs not caught by others. But as far as BAT
> >>goes the likelihood of this catching something not caught by others
> >>within BAT is very very small.
> >But given that we have 50k gem tests in full igt, does it really make
> >sense to keep it? Imo there's not much point in keeping around every
> >minute combinatorial variation if it means we can never run the full set
> >of testcases. Some serious trimming of the herd is probably called for.
> >
> >Joonas/Tvrtko/Mika and other gem folks: What's your stance here?
> 
> I am very fond of gem_storedw_loop, it was indispensable during
> platform bringup in Fulsim in a not so distant past.
> 
> Even if not so, it is a very short and simple test ("Basic CS check
> using MI_STORE_DATA_IMM"), while gem_sync is much more complex and
> deals with a different issues.

See gem_exec_store for an even shorter sanity test of CS (also in BAT).
We have overlap between this, gem_exec_basic, gem_exec_store,
gem_exec_nop, gem_ringfill and gem_sync.

> Without going into wider discussion, I vote to keep this particular test.

In BAT?
-Chris

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

Re: [Intel-gfx] i915 monitor hotplug on 4.1/4.4 PREEMPT

[Jani Nikula]

On Thu, 20 Oct 2016, David Weinehall  wrote:
> On Thu, Oct 20, 2016 at 03:28:10PM +0300, Jani Nikula wrote:
>> On Thu, 20 Oct 2016, Nicolae Rosia  wrote:
>> > Monitor hotplugging seems to be broken on latest 4.1/4.4 RT kernel with 
>> > i915.
>> > I have tested this on non-RT kernel and it works.
>
> The answer to your first question seems to be here :)

*blush*

>> > I get an udev event for unplugging, but there's no event generated for
>> > plugging the monitor back in.
>> 
>> Does it work on non-RT? Does it work on v4.8 or v4.9-rc1?
>
> The second one is relevant though. 4.1 is pre-historic, 4.4 is ancient.

I think the honest answer here is that we do not have the resources to
debug RT vs. non-RT issues all that much in general, and especially not
for such old kernels. RT is not in our focus, and hotplug has proved to
be hard enough on non-RT. Nothing to be proud of, but we have 500+ bugs
open over at the freedesktop.org bugzilla, most for relatively recent
non-RT kernels.

Even if we fixed this upstream (and it would have to be fixed upstream
to be backported) it's a huge problem that the feedback loop for RT
kernels has such a long delay. If we break something for RT, it takes
forever for us to find out.


BR,
Jani.

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

Re: [Intel-gfx] i915 monitor hotplug on 4.1/4.4 PREEMPT

[Nicolae Rosia]

Hi,

On Thu, Oct 20, 2016 at 3:57 PM, David Weinehall  wrote:
>> > I get an udev event for unplugging, but there's no event generated for
>> > plugging the monitor back in.
>>
>> Does it work on non-RT? Does it work on v4.8 or v4.9-rc1?
>
> The second one is relevant though. 4.1 is pre-historic, 4.4 is ancient.
I just tested this on v4.8.2-rt2 and it works.

Any tips on what I should do next, excluding the upgrade :-) ?

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

Re: [Intel-gfx] [PATCH 39/41] drm/i915: Enable multiple timelines

[Chris Wilson]

On Thu, Oct 20, 2016 at 06:26:04PM +0300, Joonas Lahtinen wrote:
> On pe, 2016-10-14 at 13:18 +0100, Chris Wilson wrote:
> > With the infrastructure converted over to tracking multiple timelines in
> > the GEM API whilst preserving the efficiency of using a single execution
> > timeline internally, we can now assign a separate timeline to every
> > context with full-ppgtt.
> > 
> > Signed-off-by: Chris Wilson 
> 
> Changelog would be nice, but seems to address the major issues.

v2: Add a comment to indicate the xfer between timelines upon
submission.

? Are we on the right thread?

Most the earliest issues where addressed by doing them before we got to
the enabling patch.
-Chris

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

Re: [Intel-gfx] [PATCH 15/41] drm/i915: Use a radixtree for random access to the object's backing storage

[Tvrtko Ursulin]

On 20/10/2016 16:03, Chris Wilson wrote:

A while ago we switched from a contiguous array of pages into an sglist,
for that was both more convenient for mapping to hardware and avoided
the requirement for a vmalloc array of pages on every object. However,
certain GEM API calls (like pwrite, pread as well as performing
relocations) do desire access to individual struct pages. A quick hack
was to introduce a cache of the last access such that finding the
following page was quick - this works so long as the caller desired
sequential access. Walking backwards, or multiple callers, still hits a
slow linear search for each page. One solution is to store each
successful lookup in a radix tree.

v2: Rewrite building the radixtree for clarity, hopefully.

v3: Rearrange execbuf to avoid calling i915_gem_object_get_sg() from
within an atomic section and so relax the allocation context to a simple
GFP_KERNEL and mutex.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h |  69 +---
 drivers/gpu/drm/i915/i915_gem.c | 185 +---
 drivers/gpu/drm/i915/i915_gem_stolen.c  |   4 +-
 drivers/gpu/drm/i915/i915_gem_userptr.c |   4 +-
 4 files changed, 199 insertions(+), 63 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0897f43e7796..e2e48af8d41f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2273,9 +2273,12 @@ struct drm_i915_gem_object {

struct sg_table *pages;
int pages_pin_count;
-   struct get_page {
-   struct scatterlist *sg;
-   int last;
+   struct i915_gem_object_page_iter {
+   struct scatterlist *sg_pos;
+   unsigned int sg_idx; /* in pages, but 32bit eek! */
+
+   struct radix_tree_root radix;
+   struct mutex lock; /* protects this cache */
} get_page;
void *mapping;

@@ -2478,6 +2481,14 @@ static __always_inline struct sgt_iter {
return s;
 }

+static inline struct scatterlist *sg_next(struct scatterlist *sg)
+{
+   ++sg;
+   if (unlikely(sg_is_chain(sg)))
+   sg = sg_chain_ptr(sg);
+   return sg;
+}
+
 /**
  * __sg_next - return the next scatterlist entry in a list
  * @sg:The current sg entry
@@ -2492,9 +2503,7 @@ static inline struct scatterlist *__sg_next(struct 
scatterlist *sg)
 #ifdef CONFIG_DEBUG_SG
BUG_ON(sg->sg_magic != SG_MAGIC);
 #endif
-   return sg_is_last(sg) ? NULL :
-   likely(!sg_is_chain(++sg)) ? sg :
-   sg_chain_ptr(sg);
+   return sg_is_last(sg) ? NULL : sg_next(sg);
 }

 /**
@@ -3172,45 +3181,21 @@ static inline int __sg_page_count(struct scatterlist 
*sg)
return sg->length >> PAGE_SHIFT;
 }

-struct page *
-i915_gem_object_get_dirty_page(struct drm_i915_gem_object *obj, int n);
-
-static inline dma_addr_t
-i915_gem_object_get_dma_address(struct drm_i915_gem_object *obj, int n)
-{
-   if (n < obj->get_page.last) {
-   obj->get_page.sg = obj->pages->sgl;
-   obj->get_page.last = 0;
-   }
-
-   while (obj->get_page.last + __sg_page_count(obj->get_page.sg) <= n) {
-   obj->get_page.last += __sg_page_count(obj->get_page.sg++);
-   if (unlikely(sg_is_chain(obj->get_page.sg)))
-   obj->get_page.sg = sg_chain_ptr(obj->get_page.sg);
-   }
+struct scatterlist *
+i915_gem_object_get_sg(struct drm_i915_gem_object *obj,
+  unsigned int n, unsigned int *offset);

-   return sg_dma_address(obj->get_page.sg) + ((n - obj->get_page.last) << 
PAGE_SHIFT);
-}
-
-static inline struct page *
-i915_gem_object_get_page(struct drm_i915_gem_object *obj, int n)
-{
-   if (WARN_ON(n >= obj->base.size >> PAGE_SHIFT))
-   return NULL;
-
-   if (n < obj->get_page.last) {
-   obj->get_page.sg = obj->pages->sgl;
-   obj->get_page.last = 0;
-   }
+struct page *
+i915_gem_object_get_page(struct drm_i915_gem_object *obj,
+unsigned int n);

-   while (obj->get_page.last + __sg_page_count(obj->get_page.sg) <= n) {
-   obj->get_page.last += __sg_page_count(obj->get_page.sg++);
-   if (unlikely(sg_is_chain(obj->get_page.sg)))
-   obj->get_page.sg = sg_chain_ptr(obj->get_page.sg);
-   }
+struct page *
+i915_gem_object_get_dirty_page(struct drm_i915_gem_object *obj,
+  unsigned int n);

-   return nth_page(sg_page(obj->get_page.sg), n - obj->get_page.last);
-}
+dma_addr_t
+i915_gem_object_get_dma_address(struct drm_i915_gem_object *obj,
+   unsigned long n);

 static inline void i915_gem_object_pin_pages(struct drm_i915_gem_object *obj)
 {
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d596b1f9e969..a9ea20d53e23 

Re: [Intel-gfx] [PATCH 3/8] drm/i915/skl+: Remove minimum block allocation from crtc state.

[Paulo Zanoni]

Em Qua, 2016-10-19 às 15:13 -0700, Matt Roper escreveu:
> On Wed, Oct 12, 2016 at 03:28:16PM +0200, Maarten Lankhorst wrote:
> > 
> > This is not required any more now that we get fresh state from
> > drm_atomic_crtc_state_for_each_plane_state. Zero all state
> > in advance.
> > 
> > Signed-off-by: Maarten Lankhorst  > >
> 
> Reviewed-by: Matt Roper 

Reviewed-by: Paulo Zanoni 

You could also get rid of the unsafe loop that computes alloc_size:
just do it in the main loop now that we iterate over everything. But
this can be done in a separate patch.

> 
> > 
> > ---
> >  drivers/gpu/drm/i915/intel_drv.h |  4 
> >  drivers/gpu/drm/i915/intel_pm.c  | 15 +--
> >  2 files changed, 5 insertions(+), 14 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 888054518f3c..a176e6cebab3 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -501,10 +501,6 @@ struct intel_crtc_wm_state {
> >     /* gen9+ only needs 1-step wm programming
> > */
> >     struct skl_pipe_wm optimal;
> >     struct skl_ddb_entry ddb;
> > -
> > -   /* minimum block allocation */
> > -   uint16_t minimum_blocks[I915_MAX_PLANES];
> > -   uint16_t
> > minimum_y_blocks[I915_MAX_PLANES];
> >     } skl;
> >     };
> >  
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 97b6202c4097..83c1b0acef38 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -3356,8 +3356,8 @@ skl_allocate_pipe_ddb(struct intel_crtc_state
> > *cstate,
> >     enum pipe pipe = intel_crtc->pipe;
> >     struct skl_ddb_entry *alloc = >wm.skl.ddb;
> >     uint16_t alloc_size, start, cursor_blocks;
> > -   uint16_t *minimum = cstate->wm.skl.minimum_blocks;
> > -   uint16_t *y_minimum = cstate->wm.skl.minimum_y_blocks;
> > +   uint16_t minimum[I915_MAX_PLANES] = {};
> > +   uint16_t y_minimum[I915_MAX_PLANES] = {};
> >     unsigned int total_data_rate;
> >     int num_active;
> >     int id, i;
> > @@ -3398,16 +3398,11 @@ skl_allocate_pipe_ddb(struct
> > intel_crtc_state *cstate,
> >     if (intel_plane->pipe != pipe)
> >     continue;
> >  
> > -   if (!pstate->visible) {
> > -   minimum[id] = 0;
> > -   y_minimum[id] = 0;
> > +   if (!pstate->visible)
> >     continue;
> > -   }
> > -   if (plane->type == DRM_PLANE_TYPE_CURSOR) {
> > -   minimum[id] = 0;
> > -   y_minimum[id] = 0;
> > +
> > +   if (plane->type == DRM_PLANE_TYPE_CURSOR)
> >     continue;
> > -   }
> >  
> >     minimum[id] = skl_ddb_min_alloc(pstate, 0);
> >     y_minimum[id] = skl_ddb_min_alloc(pstate, 1);
> > -- 
> > 2.7.4
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] shmem: Support for registration of Driver/file owner specific ops

[Joonas Lahtinen]

On ke, 2016-10-19 at 20:41 +0530, akash goel wrote:
> On Thu, Mar 24, 2016 at 5:41 PM, Joonas Lahtinen
> >  wrote:
> > On ke, 2016-03-23 at 11:39 +0530, akash.g...@intel.com wrote:
> > > @@ -34,11 +34,28 @@ struct shmem_sb_info {
> > >   struct mempolicy *mpol; /* default memory policy for mappings */
> > >  };
> > > 
> > > +struct shmem_dev_info {
> > > + void *dev_private_data;
> > > + int (*dev_migratepage)(struct address_space *mapping,
> > > +struct page *newpage, struct page *page,
> > > +enum migrate_mode mode, void *dev_priv_data);
> > 
> > One might want to have a separate shmem_dev_operations struct or
> > similar.
> > 
> Sorry for the very late turnaround.
> 
> Sorry couldn't get your point here. Are you suggesting to rename the
> structure to shmem_dev_operations ?

I'm pretty sure I was after putting migratepage function pointer in
shmem_dev_operations struct, but I think that can be done once there
are more functions.

s/dev_private_data/private_data/ and s/dev_priv_data/private_data/
might be in order, too. I should be obvious from context.

> > > +};
> > > +
> > >  static inline struct shmem_inode_info *SHMEM_I(struct inode *inode)
> > >  {
> > >   return container_of(inode, struct shmem_inode_info, vfs_inode);
> > >  }
> > > 
> > > +static inline int shmem_set_device_ops(struct address_space *mapping,
> > > + struct shmem_dev_info *info)
> > > +{

This name could be shmem_set_dev_info, if there will be separate _ops
struct in future.

> > > + if (mapping->private_data != NULL)
> > > + return -EEXIST;
> > > +
> > 
> > I did a quick random peek and most set functions are just void and
> > override existing data. I'd suggest the same.
> > 
> > > 
> > > + mapping->private_data = info;
> > 
> Fine will change the return type to void and remove the check.
> 
> > 
> > Also, doesn't this kinda steal the mapping->private_data, might that be
> > unexpected for the user? I notice currently it's not being touched at
> > all.
> > 
> Sorry by User do you mean the shmem client who called shmem_file_setup() ?
> It seems clients are not expected to touch mapping->private_data and
> so shmemfs can safely use it.

If it's not used by others, should be fine. Not sure if WARN would be
in place, Chris?

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 39/41] drm/i915: Enable multiple timelines

[Joonas Lahtinen]

On pe, 2016-10-14 at 13:18 +0100, Chris Wilson wrote:
> With the infrastructure converted over to tracking multiple timelines in
> the GEM API whilst preserving the efficiency of using a single execution
> timeline internally, we can now assign a separate timeline to every
> context with full-ppgtt.
> 
> Signed-off-by: Chris Wilson 

Changelog would be nice, but seems to address the major issues.

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 16/18] drm/i915: Enable multiple timelines

[Joonas Lahtinen]

On to, 2016-10-20 at 13:49 +0100, Chris Wilson wrote:
> On Mon, Sep 19, 2016 at 06:52:13PM +0300, Joonas Lahtinen wrote:
> > 
> > On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote:
> > > 
> > > @@ -315,17 +304,42 @@ submit_notify(struct i915_sw_fence *fence, enum 
> > > i915_sw_fence_notify state)
> > >  {
> > >   struct drm_i915_gem_request *request =
> > >   container_of(fence, typeof(*request), submit);
> > > + struct intel_timeline *timeline;
> > > + struct intel_engine_cs *engine = request->engine;
> > > + unsigned long flags;
> > > + u32 seqno;
> > >  
> > >   /* Will be called from irq-context when using foreign DMA fences */
> > >  
> > > - switch (state) {
> > > - case FENCE_COMPLETE:
> > > - request->engine->submit_request(request);
> > > - break;
> > > + if (state != FENCE_COMPLETE)
> > > + return NOTIFY_DONE;
> > >  
> > > - case FENCE_FREE:
> > > - break;
> > > - }
> > > + timeline = engine->timeline;
> > > + GEM_BUG_ON(timeline == request->timeline);
> > 
> > Umm, why this BUG_ON?
> 
> To document that the intent here is to move from the per-context
> timeline onto the global per-engine timeline. If the request was already
> on the engine->timeline bad things would happen, at the very simplest a
> deadlock here.

I see. I would have lifted the assignment and the BUG_ON before actual
code, like elsewhere. But I can live with this too.

The new patch seems to have got rid of the emit_request weirdness too,
so I'll add by R-b there.

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 08/41] drm/i915: Remove superfluous wait_for_error() from throttle-ioctl

[Joonas Lahtinen]

On to, 2016-10-20 at 16:03 +0100, Chris Wilson wrote:

> Reviewed-by: Joonas Lahtinen " at the end of line.

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/2] drm/i915/lspcon: Add workaround for resuming in PCON mode

[Imre Deak]

On my APL the LSPCON firmware resumes in PCON mode as opposed to the
expected LS mode. It also appears to be in a state where AUX DPCD reads
will succeed but return garbage recovering only after a few hundreds of
milliseconds. After the recovery time DPCD reads will result in the
correct values and things will continue to work. If I2C over AUX is
attempted during this recovery time (implying an AUX write transaction)
the firmware won't recover and will stay in this broken state.

As a workaround check if the firmware is in PCON state after resume and
if so wait until the correct DPCD values are returned. For this we
compare the branch descriptor with the one we cached during init time.
If the firmware was in the LS state, we skip the w/a and continue as
before.

Cc: Shashank Sharma 
Cc: Ville Syrjälä 
Cc: Jani Nikula 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/intel_dp.c |  2 +-
 drivers/gpu/drm/i915/intel_drv.h|  6 -
 drivers/gpu/drm/i915/intel_lspcon.c | 52 ++---
 3 files changed, 48 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index e90211e..ec031db 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3487,7 +3487,7 @@ intel_dp_link_down(struct intel_dp *intel_dp)
intel_dp->DP = DP;
 }
 
-static bool
+bool
 intel_dp_read_dpcd(struct intel_dp *intel_dp)
 {
if (drm_dp_dpcd_read(_dp->aux, 0x000, intel_dp->dpcd,
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index a35e241..9a2366e 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -972,7 +972,9 @@ struct intel_dp {
 struct intel_lspcon {
bool active;
enum drm_lspcon_mode mode;
-   struct drm_dp_aux *aux;
+   struct intel_dp *intel_dp;
+   bool desc_valid;
+   struct intel_dp_desc desc;
 };
 
 struct intel_digital_port {
@@ -1469,6 +1471,8 @@ static inline unsigned int intel_dp_unused_lane_mask(int 
lane_count)
 }
 
 bool
+intel_dp_read_dpcd(struct intel_dp *intel_dp);
+bool
 intel_dp_read_desc(struct intel_dp *intel_dp, struct intel_dp_desc *desc);
 void
 intel_dp_print_desc(struct intel_dp *intel_dp, struct intel_dp_desc *desc);
diff --git a/drivers/gpu/drm/i915/intel_lspcon.c 
b/drivers/gpu/drm/i915/intel_lspcon.c
index d2c8cb2..54c6173 100644
--- a/drivers/gpu/drm/i915/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/intel_lspcon.c
@@ -30,7 +30,7 @@
 static enum drm_lspcon_mode lspcon_get_current_mode(struct intel_lspcon 
*lspcon)
 {
enum drm_lspcon_mode current_mode = DRM_LSPCON_MODE_INVALID;
-   struct i2c_adapter *adapter = >aux->ddc;
+   struct i2c_adapter *adapter = >intel_dp->aux.ddc;
 
if (drm_lspcon_get_mode(adapter, _mode))
DRM_ERROR("Error reading LSPCON mode\n");
@@ -45,7 +45,7 @@ static int lspcon_change_mode(struct intel_lspcon *lspcon,
 {
int err;
enum drm_lspcon_mode current_mode;
-   struct i2c_adapter *adapter = >aux->ddc;
+   struct i2c_adapter *adapter = >intel_dp->aux.ddc;
 
err = drm_lspcon_get_mode(adapter, _mode);
if (err) {
@@ -72,7 +72,7 @@ static int lspcon_change_mode(struct intel_lspcon *lspcon,
 static bool lspcon_probe(struct intel_lspcon *lspcon)
 {
enum drm_dp_dual_mode_type adaptor_type;
-   struct i2c_adapter *adapter = >aux->ddc;
+   struct i2c_adapter *adapter = >intel_dp->aux.ddc;
 
/* Lets probe the adaptor and check its type */
adaptor_type = drm_dp_dual_mode_detect(adapter);
@@ -89,8 +89,42 @@ static bool lspcon_probe(struct intel_lspcon *lspcon)
return true;
 }
 
+static void lspcon_resume_in_pcon_wa(struct intel_lspcon *lspcon)
+{
+   unsigned long start = jiffies;
+
+   if (!lspcon->desc_valid)
+   return;
+
+   while (1) {
+   struct intel_dp_desc desc;
+
+   /*
+* The w/a only applies in PCON mode and we don't expect any
+* AUX errors.
+*/
+   if (!intel_dp_read_desc(lspcon->intel_dp, ))
+   return;
+
+   if (!memcmp(>desc, , sizeof(desc))) {
+   DRM_DEBUG_KMS("LSPCON recovering in PCON mode after %u 
ms\n",
+ jiffies_to_msecs(jiffies - start));
+   return;
+   }
+
+   if (time_after(jiffies, start + msecs_to_jiffies(1000)))
+   break;
+
+   msleep(10);
+   }
+
+   DRM_DEBUG_KMS("LSPCON DP descriptor mismatch after resume\n");
+}
+
 void lspcon_resume(struct intel_lspcon *lspcon)
 {
+   lspcon_resume_in_pcon_wa(lspcon);
+
if (lspcon_change_mode(lspcon, DRM_LSPCON_MODE_PCON, true))
DRM_ERROR("LSPCON resume failed\n");
else

[Intel-gfx] [PATCH 1/2] drm/i915/dp: Print full branch/sink descriptor for all outputs

[Imre Deak]

Extend the branch/sink descriptor info with the missing device ID
field and print this info for eDP and LSPCON connectors too.

Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/intel_dp.c | 83 +++--
 drivers/gpu/drm/i915/intel_drv.h| 13 ++
 drivers/gpu/drm/i915/intel_lspcon.c |  7 
 3 files changed, 53 insertions(+), 50 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 88f3b74..e90211e 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1442,42 +1442,34 @@ static void intel_dp_print_rates(struct intel_dp 
*intel_dp)
DRM_DEBUG_KMS("common rates: %s\n", str);
 }
 
-static void intel_dp_print_hw_revision(struct intel_dp *intel_dp)
+static bool intel_dp_is_branch(struct intel_dp *intel_dp)
 {
-   uint8_t rev;
-   int len;
-
-   if ((drm_debug & DRM_UT_KMS) == 0)
-   return;
-
-   if (!(intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] &
- DP_DWN_STRM_PORT_PRESENT))
-   return;
-
-   len = drm_dp_dpcd_read(_dp->aux, DP_BRANCH_HW_REV, , 1);
-   if (len < 0)
-   return;
-
-   DRM_DEBUG_KMS("sink hw revision: %d.%d\n", (rev & 0xf0) >> 4, rev & 
0xf);
+   return intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] &
+  DP_DWN_STRM_PORT_PRESENT;
 }
 
-static void intel_dp_print_sw_revision(struct intel_dp *intel_dp)
+bool
+intel_dp_read_desc(struct intel_dp *intel_dp, struct intel_dp_desc *desc)
 {
-   uint8_t rev[2];
-   int len;
+   u32 base = intel_dp_is_branch(intel_dp) ? DP_BRANCH_OUI : DP_SINK_OUI;
 
-   if ((drm_debug & DRM_UT_KMS) == 0)
-   return;
+   return drm_dp_dpcd_read(_dp->aux, base, desc, sizeof(*desc)) ==
+  sizeof(*desc);
+}
 
-   if (!(intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] &
- DP_DWN_STRM_PORT_PRESENT))
-   return;
+void
+intel_dp_print_desc(struct intel_dp *intel_dp, struct intel_dp_desc *desc)
+{
+   const char *dev_type = intel_dp_is_branch(intel_dp) ? "branch" : "sink";
+   bool oui_sup = intel_dp->dpcd[DP_DOWN_STREAM_PORT_COUNT] &
+  DP_OUI_SUPPORT;
 
-   len = drm_dp_dpcd_read(_dp->aux, DP_BRANCH_SW_REV, , 2);
-   if (len < 0)
-   return;
-
-   DRM_DEBUG_KMS("sink sw revision: %d.%d\n", rev[0], rev[1]);
+   DRM_DEBUG_KMS("DP %s: OUI %*phD%s dev-ID %.*s HW-rev %d.%d SW-rev 
%d.%d\n",
+ dev_type,
+ (int)sizeof(desc->oui), desc->oui, oui_sup ? "" : "(NS)",
+ (int)sizeof(desc->device_id), desc->device_id,
+ (desc->hw_rev & 0xf0) >> 4, (desc->hw_rev & 0xf),
+ desc->sw_major_rev, desc->sw_minor_rev);
 }
 
 static int rate_to_index(int find, const int *rates)
@@ -3519,6 +3511,13 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
if (!intel_dp_read_dpcd(intel_dp))
return false;
 
+   if (drm_debug & DRM_UT_KMS) {
+   struct intel_dp_desc desc;
+
+   if (intel_dp_read_desc(intel_dp, ))
+   intel_dp_print_desc(intel_dp, );
+   }
+
if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11)
dev_priv->no_aux_handshake = intel_dp->dpcd[DP_MAX_DOWNSPREAD] &
DP_NO_AUX_HANDSHAKE_LINK_TRAINING;
@@ -3621,23 +3620,6 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
return true;
 }
 
-static void
-intel_dp_probe_oui(struct intel_dp *intel_dp)
-{
-   u8 buf[3];
-
-   if (!(intel_dp->dpcd[DP_DOWN_STREAM_PORT_COUNT] & DP_OUI_SUPPORT))
-   return;
-
-   if (drm_dp_dpcd_read(_dp->aux, DP_SINK_OUI, buf, 3) == 3)
-   DRM_DEBUG_KMS("Sink OUI: %02hx%02hx%02hx\n",
- buf[0], buf[1], buf[2]);
-
-   if (drm_dp_dpcd_read(_dp->aux, DP_BRANCH_OUI, buf, 3) == 3)
-   DRM_DEBUG_KMS("Branch OUI: %02hx%02hx%02hx\n",
- buf[0], buf[1], buf[2]);
-}
-
 static bool
 intel_dp_can_mst(struct intel_dp *intel_dp)
 {
@@ -4410,11 +4392,12 @@ intel_dp_long_pulse(struct intel_connector 
*intel_connector)
  yesno(drm_dp_tps3_supported(intel_dp->dpcd)));
 
intel_dp_print_rates(intel_dp);
+   if (drm_debug & DRM_UT_KMS) {
+   struct intel_dp_desc desc;
 
-   intel_dp_probe_oui(intel_dp);
-
-   intel_dp_print_hw_revision(intel_dp);
-   intel_dp_print_sw_revision(intel_dp);
+   if (intel_dp_read_desc(intel_dp, ))
+   intel_dp_print_desc(intel_dp, );
+   }
 
intel_dp_configure_mst(intel_dp);
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index c06a33e..a35e241 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -883,6 +883,14 @@ enum link_m_n_set {
M2_N2
 };
 
+struct intel_dp_desc {
+   u8 

Re: [Intel-gfx] [PATCH 2/8] drm/i915/skl+: Remove data_rate from watermark struct.

[Paulo Zanoni]

Em Qui, 2016-10-20 às 15:18 -0200, Paulo Zanoni escreveu:
> Em Qua, 2016-10-19 às 15:13 -0700, Matt Roper escreveu:
> > 
> > On Wed, Oct 12, 2016 at 03:28:15PM +0200, Maarten Lankhorst wrote:
> > > 
> > > 
> > > It's only used in one function, and can be calculated without
> > > caching it
> > > in the global struct by using
> > > drm_atomic_crtc_state_for_each_plane_state.
> > > 
> > > Signed-off-by: Maarten Lankhorst  > > om
> > > > 
> > > > 
> > > ---
> > >  drivers/gpu/drm/i915/intel_drv.h |  4 
> > >  drivers/gpu/drm/i915/intel_pm.c  | 44 +++---
> > > --
> > > 
> > >  2 files changed, 21 insertions(+), 27 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > > b/drivers/gpu/drm/i915/intel_drv.h
> > > index bb468c974e14..888054518f3c 100644
> > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > @@ -502,10 +502,6 @@ struct intel_crtc_wm_state {
> > >   struct skl_pipe_wm optimal;
> > >   struct skl_ddb_entry ddb;
> > >  
> > > - /* cached plane data rate */
> > > - unsigned
> > > plane_data_rate[I915_MAX_PLANES];
> > > - unsigned
> > > plane_y_data_rate[I915_MAX_PLANES];
> > > -
> > >   /* minimum block allocation */
> > >   uint16_t
> > > minimum_blocks[I915_MAX_PLANES];
> > >   uint16_t
> > > minimum_y_blocks[I915_MAX_PLANES];
> > > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > > b/drivers/gpu/drm/i915/intel_pm.c
> > > index b96a899c899d..97b6202c4097 100644
> > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > @@ -3236,12 +3236,13 @@ skl_plane_relative_data_rate(const struct
> > > intel_crtc_state *cstate,
> > >   *   3 * 4096 * 8192  * 4 < 2^32
> > >   */
> > >  static unsigned int
> > > -skl_get_total_relative_data_rate(struct intel_crtc_state
> > > *intel_cstate)
> > > +skl_get_total_relative_data_rate(struct intel_crtc_state
> > > *intel_cstate,
> > > +  unsigned *plane_data_rate,
> > > +  unsigned *plane_y_data_rate)
> > >  {
> > >   struct drm_crtc_state *cstate = _cstate->base;
> > >   struct drm_atomic_state *state = cstate->state;
> > >   struct drm_crtc *crtc = cstate->crtc;
> > > - struct drm_device *dev = crtc->dev;
> > >   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> > >   struct drm_plane *plane;
> > >   const struct intel_plane *intel_plane;
> > > @@ -3263,21 +3264,16 @@ skl_get_total_relative_data_rate(struct
> > > intel_crtc_state *intel_cstate)
> > >   /* packed/uv */
> > >   rate =
> > > skl_plane_relative_data_rate(intel_cstate,
> > >   pstate, 0);
> > > - intel_cstate->wm.skl.plane_data_rate[id] = rate;
> > > + plane_data_rate[id] = rate;
> > > +
> > > + total_data_rate += rate;
> > >  
> > >   /* y-plane */
> > >   rate =
> > > skl_plane_relative_data_rate(intel_cstate,
> > >   pstate, 1);
> > > - intel_cstate->wm.skl.plane_y_data_rate[id] =
> > > rate;
> > > - }
> > > -
> > > - /* Calculate CRTC's total data rate from cached values
> > > */
> > > - for_each_intel_plane_on_crtc(dev, intel_crtc,
> > > intel_plane)
> > > {
> > > - int id = skl_wm_plane_id(intel_plane);
> > > + plane_y_data_rate[id] = rate;
> > >  
> > > - /* packed/uv */
> > > - total_data_rate += intel_cstate-
> > > > 
> > > > wm.skl.plane_data_rate[id];
> > > - total_data_rate += intel_cstate-
> > > > 
> > > > wm.skl.plane_y_data_rate[id];
> > > + total_data_rate += rate;
> > >   }
> > >  
> > >   return total_data_rate;
> > > @@ -3366,6 +3362,9 @@ skl_allocate_pipe_ddb(struct
> > > intel_crtc_state
> > > *cstate,
> > >   int num_active;
> > >   int id, i;
> > >  

Also obligatory bikeshed to remove the ugly blank line above :)

> > > + unsigned data_rate[I915_MAX_PLANES] = {};
> > > + unsigned y_data_rate[I915_MAX_PLANES] = {};
> > > +
> > 
> > Minor nitpick; if you picked a different names here (e.g.,
> > plane_data_rate[]) then you could leave the local variables farther
> > down
> > named 'data_rate' and 'y_data_rate' which would reduce the diff
> > changes
> > and result in a slightly smaller patch.
> > 
> > Whether or not you feel like making that change, killing the
> > caching
> > is
> > good so,
> > 
> > Reviewed-by: Matt Roper 
> > 
> > 
> > > 
> > > 
> > >   /* Clear the partitioning for disabled planes. */
> > >   memset(ddb->plane[pipe], 0, sizeof(ddb->plane[pipe]));
> > >   memset(ddb->y_plane[pipe], 0, sizeof(ddb-
> > > >y_plane[pipe]));
> > > @@ -3425,29 +3424,28 @@ skl_allocate_pipe_ddb(struct
> > > intel_crtc_state *cstate,
> > >    *
> > >    * FIXME: we may not allocate every single block here.
> > >    */
> > > - 

[Intel-gfx] [PATCH 23/41] drm/i915: Acquire the backing storage outside of struct_mutex in set-domain

[Chris Wilson]

As we can locklessly (well struct_mutex-lessly) acquire the backing
storage, do so in set-domain-ioctl to reduce the contention on the
struct_mutex.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem.c | 99 +
 1 file changed, 61 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index ba311a104564..697a83823920 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1451,6 +1451,30 @@ write_origin(struct drm_i915_gem_object *obj, unsigned 
domain)
obj->frontbuffer_ggtt_origin : ORIGIN_CPU);
 }
 
+static void i915_gem_object_bump_inactive_ggtt(struct drm_i915_gem_object *obj)
+{
+   struct drm_i915_private *i915;
+   struct list_head *list;
+   struct i915_vma *vma;
+
+   list_for_each_entry(vma, >vma_list, obj_link) {
+   if (!i915_vma_is_ggtt(vma))
+   continue;
+
+   if (i915_vma_is_active(vma))
+   continue;
+
+   if (!drm_mm_node_allocated(>node))
+   continue;
+
+   list_move_tail(>vm_link, >vm->inactive_list);
+   }
+
+   i915 = to_i915(obj->base.dev);
+   list = obj->bind_count ? >mm.bound_list : >mm.unbound_list;
+   list_move_tail(>global_list, list);
+}
+
 /**
  * Called when user space prepares to use an object with the CPU, either
  * through the mmap ioctl's mapping or a GTT mapping.
@@ -1466,7 +1490,7 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void 
*data,
struct drm_i915_gem_object *obj;
uint32_t read_domains = args->read_domains;
uint32_t write_domain = args->write_domain;
-   int ret;
+   int err;
 
/* Only handle setting domains to types used by the CPU. */
if ((write_domain | read_domains) & I915_GEM_GPU_DOMAINS)
@@ -1486,33 +1510,48 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void 
*data,
 * We will repeat the flush holding the lock in the normal manner
 * to catch cases where we are gazumped.
 */
-   ret = i915_gem_object_wait(obj,
+   err = i915_gem_object_wait(obj,
   I915_WAIT_INTERRUPTIBLE |
   (write_domain ? I915_WAIT_ALL : 0),
   MAX_SCHEDULE_TIMEOUT,
   to_rps_client(file));
-   if (ret)
-   goto err;
+   if (err)
+   goto out_unlocked;
 
-   ret = i915_mutex_lock_interruptible(dev);
-   if (ret)
-   goto err;
+   /* Flush and acquire obj->pages so that we are coherent through
+* direct access in memory with previous cached writes through
+* shmemfs and that our cache domain tracking remains valid.
+* For example, if the obj->filp was moved to swap without us
+* being notified and releasing the pages, we would mistakenly
+* continue to assume that the obj remained out of the CPU cached
+* domain.
+*/
+   err = i915_gem_object_pin_pages(obj);
+   if (err)
+   goto out_unlocked;
+
+   err = i915_mutex_lock_interruptible(dev);
+   if (err)
+   goto out_pages;
 
if (read_domains & I915_GEM_DOMAIN_GTT)
-   ret = i915_gem_object_set_to_gtt_domain(obj, write_domain != 0);
+   err = i915_gem_object_set_to_gtt_domain(obj, write_domain != 0);
else
-   ret = i915_gem_object_set_to_cpu_domain(obj, write_domain != 0);
+   err = i915_gem_object_set_to_cpu_domain(obj, write_domain != 0);
 
-   if (write_domain != 0)
-   intel_fb_obj_invalidate(obj, write_origin(obj, write_domain));
+   /* And bump the LRU for this access */
+   i915_gem_object_bump_inactive_ggtt(obj);
 
-   i915_gem_object_put(obj);
mutex_unlock(>struct_mutex);
-   return ret;
 
-err:
+   if (write_domain != 0)
+   intel_fb_obj_invalidate(obj, write_origin(obj, write_domain));
+
+out_pages:
+   i915_gem_object_unpin_pages(obj);
+out_unlocked:
i915_gem_object_put_unlocked(obj);
-   return ret;
+   return err;
 }
 
 /**
@@ -1733,6 +1772,10 @@ int i915_gem_fault(struct vm_area_struct *area, struct 
vm_fault *vmf)
if (ret)
goto err;
 
+   ret = i915_gem_object_pin_pages(obj);
+   if (ret)
+   goto err;
+
intel_runtime_pm_get(dev_priv);
 
ret = i915_mutex_lock_interruptible(dev);
@@ -1815,6 +1858,7 @@ int i915_gem_fault(struct vm_area_struct *area, struct 
vm_fault *vmf)
mutex_unlock(>struct_mutex);
 err_rpm:
intel_runtime_pm_put(dev_priv);
+   i915_gem_object_unpin_pages(obj);
 err:
switch (ret) {
case -EIO:
@@ -3272,24 +3316,6 @@ 

[Intel-gfx] [PATCH RESEND v2] drm/i915/gen9: Remove WaEnableYV12BugFixInHalfSliceChicken7

[Arkadiusz Hiler]

Dropping WA because it was for early steppings.

It is fixed in newer preproduction and all production revisions.

v2: add references, updated commit message

References: HSD#2126385, HSD#2131381, BSID#0764
Cc: Mika Kuoppala 
Cc: Chris Wilson 
Cc: Michal Winiarski 
Signed-off-by: Arkadiusz Hiler 
---
 drivers/gpu/drm/i915/intel_ringbuffer.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index e107455..32786ba 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -849,10 +849,8 @@ static int gen9_init_workarounds(struct intel_engine_cs 
*engine)
 */
}
 
-   /* WaEnableYV12BugFixInHalfSliceChicken7:skl,bxt,kbl */
/* WaEnableSamplerGPGPUPreemptionSupport:skl,bxt,kbl */
WA_SET_BIT_MASKED(GEN9_HALF_SLICE_CHICKEN7,
- GEN9_ENABLE_YV12_BUGFIX |
  GEN9_ENABLE_GPGPU_PREEMPTION);
 
/* Wa4x4STCOptimizationDisable:skl,bxt,kbl */
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH 12/41] drm/i915: Introduce an internal allocator for disposable private objects

[Tvrtko Ursulin]

On 20/10/2016 16:03, Chris Wilson wrote:

Quite a few of our objects used for internal hardware programming do not
benefit from being swappable or from being zero initialised. As such
they do not benefit from using a shmemfs backing storage and since they
are internal and never directly exposed to the user, we do not need to
worry about providing a filp. For these we can use an
drm_i915_gem_object wrapper around a sg_table of plain struct page. They
are not swap backed and not automatically pinned. If they are reaped
by the shrinker, the pages are released and the contents discarded. For
the internal use case, this is fine as for example, ringbuffers are
pinned from being written by a request to be read by the hardware. Once
they are idle, they can be discarded entirely. As such they are a good
match for execlist ringbuffers and a small variety of other internal
objects.

In the first iteration, this is limited to the scratch batch buffers we
use (for command parsing and state initialisation).


And the status page.



v2: Allocate physically contiguous pages, where possible.
v3: Reduce maximum order on subsequent requests following an allocation
failure.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/Makefile|   1 +
 drivers/gpu/drm/i915/i915_drv.h  |   5 +
 drivers/gpu/drm/i915/i915_gem_batch_pool.c   |  27 ++---
 drivers/gpu/drm/i915/i915_gem_internal.c | 167 +++
 drivers/gpu/drm/i915/i915_gem_render_state.c |   2 +-
 drivers/gpu/drm/i915/intel_engine_cs.c   |   2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c  |  14 ++-
 7 files changed, 194 insertions(+), 24 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_gem_internal.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 612340097f4b..7faa04c91e1a 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -35,6 +35,7 @@ i915-y += i915_cmd_parser.o \
  i915_gem_execbuffer.o \
  i915_gem_fence.o \
  i915_gem_gtt.o \
+ i915_gem_internal.o \
  i915_gem.o \
  i915_gem_render_state.o \
  i915_gem_request.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4e93c3797d90..e267e20bdcdb 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3543,6 +3543,11 @@ i915_gem_object_create_stolen_for_preallocated(struct 
drm_device *dev,
   u32 gtt_offset,
   u32 size);

+/* i915_gem_internal.c */
+struct drm_i915_gem_object *
+i915_gem_object_create_internal(struct drm_i915_private *dev_priv,
+   unsigned int size);
+
 /* i915_gem_shrinker.c */
 unsigned long i915_gem_shrink(struct drm_i915_private *dev_priv,
  unsigned long target,
diff --git a/drivers/gpu/drm/i915/i915_gem_batch_pool.c 
b/drivers/gpu/drm/i915/i915_gem_batch_pool.c
index cb25cad3318c..aa4e1e043b4e 100644
--- a/drivers/gpu/drm/i915/i915_gem_batch_pool.c
+++ b/drivers/gpu/drm/i915/i915_gem_batch_pool.c
@@ -97,9 +97,9 @@ i915_gem_batch_pool_get(struct i915_gem_batch_pool *pool,
size_t size)
 {
struct drm_i915_gem_object *obj = NULL;
-   struct drm_i915_gem_object *tmp, *next;
+   struct drm_i915_gem_object *tmp;
struct list_head *list;
-   int n;
+   int n, ret;

lockdep_assert_held(>engine->i915->drm.struct_mutex);

@@ -112,19 +112,12 @@ i915_gem_batch_pool_get(struct i915_gem_batch_pool *pool,
n = ARRAY_SIZE(pool->cache_list) - 1;
list = >cache_list[n];

-   list_for_each_entry_safe(tmp, next, list, batch_pool_link) {
+   list_for_each_entry(tmp, list, batch_pool_link) {
/* The batches are strictly LRU ordered */
if (!i915_gem_active_is_idle(>last_read[pool->engine->id],
 >base.dev->struct_mutex))
break;

-   /* While we're looping, do some clean up */
-   if (tmp->madv == __I915_MADV_PURGED) {
-   list_del(>batch_pool_link);
-   i915_gem_object_put(tmp);
-   continue;
-   }
-
if (tmp->base.size >= size) {
obj = tmp;
break;
@@ -132,19 +125,15 @@ i915_gem_batch_pool_get(struct i915_gem_batch_pool *pool,
}

if (obj == NULL) {
-   int ret;
-
-   obj = i915_gem_object_create(>engine->i915->drm, size);
+   obj = i915_gem_object_create_internal(pool->engine->i915, size);
if (IS_ERR(obj))
return obj;
-
-   ret = i915_gem_object_get_pages(obj);
-   if (ret)
-   

[Intel-gfx] [PATCH 38/41] drm/i915: Defer setting of global seqno on request to submission

[Chris Wilson]

Defer the assignment of the global seqno on a request to its submission.
In the next patch, we will only allocate the global seqno at that time,
here we are just enabling the wait-for-submission before wait-for-seqno
paths.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_request.c  | 30 +++---
 drivers/gpu/drm/i915/intel_breadcrumbs.c | 12 
 2 files changed, 31 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 0e4b03c23b49..e6d6da8370fa 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -324,14 +324,32 @@ submit_notify(struct i915_sw_fence *fence, enum 
i915_sw_fence_notify state)
struct drm_i915_gem_request *request =
container_of(fence, typeof(*request), submit);
struct intel_engine_cs *engine = request->engine;
+   struct intel_timeline *timeline;
+   u32 seqno;
 
if (state != FENCE_COMPLETE)
return NOTIFY_DONE;
 
/* Will be called from irq-context when using foreign DMA fences */
 
-   engine->timeline->last_submitted_seqno = request->fence.seqno;
+   timeline = request->timeline;
 
+   seqno = request->fence.seqno;
+   GEM_BUG_ON(!seqno);
+   GEM_BUG_ON(i915_seqno_passed(intel_engine_get_seqno(engine), seqno));
+
+   GEM_BUG_ON(i915_seqno_passed(timeline->last_submitted_seqno, seqno));
+   request->previous_seqno = timeline->last_submitted_seqno;
+   timeline->last_submitted_seqno = seqno;
+
+   /* We may be recursing from the signal callback of another i915 fence */
+   spin_lock_nested(>lock, SINGLE_DEPTH_NESTING);
+   request->global_seqno = seqno;
+   if (test_bit(FENCE_FLAG_ENABLE_SIGNAL_BIT, >fence.flags))
+   intel_engine_enable_signaling(request);
+   spin_unlock(>lock);
+
+   GEM_BUG_ON(!request->global_seqno);
engine->emit_breadcrumb(request,
request->ring->vaddr + request->postfix);
engine->submit_request(request);
@@ -427,10 +445,10 @@ i915_gem_request_alloc(struct intel_engine_cs *engine,
INIT_LIST_HEAD(>active_list);
req->i915 = dev_priv;
req->engine = engine;
-   req->global_seqno = req->fence.seqno;
req->ctx = i915_gem_context_get(ctx);
 
/* No zalloc, must clear what we need by hand */
+   req->global_seqno = 0;
req->previous_context = NULL;
req->file_priv = NULL;
req->batch = NULL;
@@ -704,15 +722,13 @@ void __i915_add_request(struct drm_i915_gem_request 
*request, bool flush_caches)
i915_sw_fence_await_sw_fence(>submit, >submit,
 >submitq);
 
-   GEM_BUG_ON(i915_seqno_passed(timeline->last_submitted_seqno,
-request->fence.seqno));
+   list_add_tail(>link, >requests);
 
-   request->emitted_jiffies = jiffies;
-   request->previous_seqno = timeline->last_pending_seqno;
timeline->last_pending_seqno = request->fence.seqno;
i915_gem_active_set(>last_request, request);
-   list_add_tail(>link, >requests);
+
list_add_tail(>ring_link, >request_list);
+   request->emitted_jiffies = jiffies;
 
i915_gem_mark_busy(engine);
 
diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index 7e65b415c535..594676363056 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -77,22 +77,26 @@ static void intel_breadcrumbs_fake_irq(unsigned long data)
 
 static void irq_enable(struct intel_engine_cs *engine)
 {
+   unsigned long flags;
+
/* Enabling the IRQ may miss the generation of the interrupt, but
 * we still need to force the barrier before reading the seqno,
 * just in case.
 */
engine->breadcrumbs.irq_posted = true;
 
-   spin_lock_irq(>i915->irq_lock);
+   spin_lock_irqsave(>i915->irq_lock, flags);
engine->irq_enable(engine);
-   spin_unlock_irq(>i915->irq_lock);
+   spin_unlock_irqrestore(>i915->irq_lock, flags);
 }
 
 static void irq_disable(struct intel_engine_cs *engine)
 {
-   spin_lock_irq(>i915->irq_lock);
+   unsigned long flags;
+
+   spin_lock_irqsave(>i915->irq_lock, flags);
engine->irq_disable(engine);
-   spin_unlock_irq(>i915->irq_lock);
+   spin_unlock_irqrestore(>i915->irq_lock, flags);
 
engine->breadcrumbs.irq_posted = false;
 }
-- 
2.9.3

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

Re: [Intel-gfx] [PATCH] drm/i915: Add i915 perf infrastructure

[Joonas Lahtinen]

On ke, 2016-10-19 at 17:35 +0100, Robert Bragg wrote:
> I'll add a default: with MISSING_CASE as that looks like an i915-
> specific convention; though it seems like a real shame to defer
> missing case issues to runtime errors instead of taking advantage of
> the compiler complaining at build time that a case has been
> forgotten.

I think the key point here is not "having MISSING_CASE", but "not
having BUG".

There has been talk about using compile time checking more effectively,
so adding default is not needed. You can keep similar code construct
but reduce into WARN_ONCE or so.

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/gvt: Implement WaForceWakeRenderDuringMmioTLBInvalidate

[Arkadiusz Hiler]

On Thu, Oct 20, 2016 at 05:29:36PM +0300, Mika Kuoppala wrote:
> Arkadiusz Hiler  writes:
> 
> > When invalidating RCS TLB the device can enter RC6 state interrupting
> > the process, therefore the need for render forcewake for the whole
> > procedure.
> >
> > This WA is needed for all production SKL SKUs.
> >
> > References: HSD#2136899, HSD#1404391274
> > Cc: Mika Kuoppala 
> > Cc: Zhenyu Wang 
> > Signed-off-by: Arkadiusz Hiler 
> > ---
> >  drivers/gpu/drm/i915/gvt/render.c | 11 +++
> >  1 file changed, 11 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/gvt/render.c 
> > b/drivers/gpu/drm/i915/gvt/render.c
> > index f54ab85..f5000ea 100644
> > --- a/drivers/gpu/drm/i915/gvt/render.c
> > +++ b/drivers/gpu/drm/i915/gvt/render.c
> > @@ -134,11 +134,22 @@ static void handle_tlb_pending_event(struct 
> > intel_vgpu *vgpu, int ring_id)
> >  
> > reg = _MMIO(regs[ring_id]);
> >
> 
> Ok not so familiar with the gvt side but I assume this is the host
> side code and thus the vgpu is not active at this stage.

That's my understanding as well. It's a code that is setting up gvt for
further use (shadow context to be exact). It's called indirectly from
intel_gvt_create_vgpu.

We should wait for Zhenyu to verify that.

> Then you could avoid some of the implicit fw dancing
> by:
> 
> diff --git a/drivers/gpu/drm/i915/gvt/render.c 
> b/drivers/gpu/drm/i915/gvt/render.c
> index feebb65..93ba156 100644
> --- a/drivers/gpu/drm/i915/gvt/render.c
> +++ b/drivers/gpu/drm/i915/gvt/render.c
> @@ -118,6 +118,7 @@ static u32 gen9_render_mocs_L3[32];
>  static void handle_tlb_pending_event(struct intel_vgpu *vgpu, int ring_id)
>  {
> struct drm_i915_private *dev_priv = vgpu->gvt->dev_priv;
> +   enum forcewake_domains fw;
> i915_reg_t reg;
> u32 regs[] = {
> [RCS] = 0x4260,
> @@ -135,11 +136,21 @@ static void handle_tlb_pending_event(struct intel_vgpu 
> *vgpu, int ring_id)
>  
> reg = _MMIO(regs[ring_id]);
>  
> -   I915_WRITE(reg, 0x1);
> +   fw = intel_uncore_forcewake_for_reg(dev_priv, reg,
> +   FW_REG_READ | FW_REG_WRITE);
>  
> -   if (wait_for_atomic((I915_READ(reg) == 0), 50))
> +   if (ring_id == RCS && IS_SKYLAKE(dev_priv))
> +   fw |= FORCEWAKE_RENDER;
> +
> +   intel_uncore_forcewake_get(dev_priv, fw);
> +
> +   I915_WRITE_FW(reg, 0x1);
> +
> +   if (wait_for_atomic((I915_READ_FW(reg) == 0), 50))
> gvt_err("timeout in invalidate ring (%d) tlb\n", ring_id);
>  
> +   intel_uncore_forcewake_put(dev_priv, fw);
> +
> 

I can go with it, although I do not have strong preference. I think my
version is a little bit easier to follow, but his is less error prone,
as you check for the WA SKU only once, during setting the FW.

Any recommendations?

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

Re: [Intel-gfx] [PATCH 2/8] drm/i915/skl+: Remove data_rate from watermark struct.

[Paulo Zanoni]

Em Qua, 2016-10-19 às 15:13 -0700, Matt Roper escreveu:
> On Wed, Oct 12, 2016 at 03:28:15PM +0200, Maarten Lankhorst wrote:
> > 
> > It's only used in one function, and can be calculated without
> > caching it
> > in the global struct by using
> > drm_atomic_crtc_state_for_each_plane_state.
> > 
> > Signed-off-by: Maarten Lankhorst  > >
> > ---
> >  drivers/gpu/drm/i915/intel_drv.h |  4 
> >  drivers/gpu/drm/i915/intel_pm.c  | 44 +++-
> > 
> >  2 files changed, 21 insertions(+), 27 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index bb468c974e14..888054518f3c 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -502,10 +502,6 @@ struct intel_crtc_wm_state {
> >     struct skl_pipe_wm optimal;
> >     struct skl_ddb_entry ddb;
> >  
> > -   /* cached plane data rate */
> > -   unsigned plane_data_rate[I915_MAX_PLANES];
> > -   unsigned
> > plane_y_data_rate[I915_MAX_PLANES];
> > -
> >     /* minimum block allocation */
> >     uint16_t minimum_blocks[I915_MAX_PLANES];
> >     uint16_t
> > minimum_y_blocks[I915_MAX_PLANES];
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index b96a899c899d..97b6202c4097 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -3236,12 +3236,13 @@ skl_plane_relative_data_rate(const struct
> > intel_crtc_state *cstate,
> >   *   3 * 4096 * 8192  * 4 < 2^32
> >   */
> >  static unsigned int
> > -skl_get_total_relative_data_rate(struct intel_crtc_state
> > *intel_cstate)
> > +skl_get_total_relative_data_rate(struct intel_crtc_state
> > *intel_cstate,
> > +    unsigned *plane_data_rate,
> > +    unsigned *plane_y_data_rate)
> >  {
> >     struct drm_crtc_state *cstate = _cstate->base;
> >     struct drm_atomic_state *state = cstate->state;
> >     struct drm_crtc *crtc = cstate->crtc;
> > -   struct drm_device *dev = crtc->dev;
> >     struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> >     struct drm_plane *plane;
> >     const struct intel_plane *intel_plane;
> > @@ -3263,21 +3264,16 @@ skl_get_total_relative_data_rate(struct
> > intel_crtc_state *intel_cstate)
> >     /* packed/uv */
> >     rate = skl_plane_relative_data_rate(intel_cstate,
> >     pstate, 0);
> > -   intel_cstate->wm.skl.plane_data_rate[id] = rate;
> > +   plane_data_rate[id] = rate;
> > +
> > +   total_data_rate += rate;
> >  
> >     /* y-plane */
> >     rate = skl_plane_relative_data_rate(intel_cstate,
> >     pstate, 1);
> > -   intel_cstate->wm.skl.plane_y_data_rate[id] = rate;
> > -   }
> > -
> > -   /* Calculate CRTC's total data rate from cached values */
> > -   for_each_intel_plane_on_crtc(dev, intel_crtc, intel_plane)
> > {
> > -   int id = skl_wm_plane_id(intel_plane);
> > +   plane_y_data_rate[id] = rate;
> >  
> > -   /* packed/uv */
> > -   total_data_rate += intel_cstate-
> > >wm.skl.plane_data_rate[id];
> > -   total_data_rate += intel_cstate-
> > >wm.skl.plane_y_data_rate[id];
> > +   total_data_rate += rate;
> >     }
> >  
> >     return total_data_rate;
> > @@ -3366,6 +3362,9 @@ skl_allocate_pipe_ddb(struct intel_crtc_state
> > *cstate,
> >     int num_active;
> >     int id, i;
> >  
> > +   unsigned data_rate[I915_MAX_PLANES] = {};
> > +   unsigned y_data_rate[I915_MAX_PLANES] = {};
> > +
> 
> Minor nitpick; if you picked a different names here (e.g.,
> plane_data_rate[]) then you could leave the local variables farther
> down
> named 'data_rate' and 'y_data_rate' which would reduce the diff
> changes
> and result in a slightly smaller patch.
> 
> Whether or not you feel like making that change, killing the caching
> is
> good so,
> 
> Reviewed-by: Matt Roper 
> 
> 
> > 
> >     /* Clear the partitioning for disabled planes. */
> >     memset(ddb->plane[pipe], 0, sizeof(ddb->plane[pipe]));
> >     memset(ddb->y_plane[pipe], 0, sizeof(ddb->y_plane[pipe]));
> > @@ -3425,29 +3424,28 @@ skl_allocate_pipe_ddb(struct
> > intel_crtc_state *cstate,
> >      *
> >      * FIXME: we may not allocate every single block here.
> >      */
> > -   total_data_rate =
> > skl_get_total_relative_data_rate(cstate);
> > +   total_data_rate = skl_get_total_relative_data_rate(cstate,
> > data_rate, y_data_rate);
> >     if (total_data_rate == 0)
> >     return 0;
> >  
> >     start = alloc->start;
> > -   for_each_intel_plane_on_crtc(dev, intel_crtc, intel_plane)
> > {
> > -   unsigned int data_rate, y_data_rate;
> > +   

Re: [Intel-gfx] [PATCH] rtc: cmos: Don't enable interrupts in the middle of the interrupt handler

[Alexandre Belloni]

On 19/10/2016 at 21:02:04 +0300, ville.syrj...@linux.intel.com wrote :
> From: Ville Syrjälä 
> 
> Using spin_lock_irq()/spin_unlock_irq() from within the interrupt
> handler is a no-no. Let's save/restore the flags to avoid turning on
> interrupts prematurely.
> 
> We hit this in a bunch of our CI systems, but for whatever reason I
> wasn't able to reproduce on my own machine, so this fix is just
> based on the backtrace.
> 
> [  202.634918] WARNING: CPU: 0 PID: 0 at kernel/locking/lockdep.c:2729 
> trace_hardirqs_on_caller+0x113/0x1b0
> [  202.634919] DEBUG_LOCKS_WARN_ON(current->hardirq_context)
> [  202.634929] Modules linked in: snd_hda_intel i915 x86_pkg_temp_thermal 
> intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel 
> lpc_ich snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi 
> snd_hda_codec snd_hwdep i2c_designware_platform i2c_designware_core 
> snd_hda_core mei_me mei snd_pcm r8169 mii sdhci_acpi sdhci mmc_core i2c_hid 
> [last unloaded: i915]
> [  202.634930] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G U  
> 4.9.0-rc1-CI-CI_DRM_1734+ #1
> [  202.634931] Hardware name: GIGABYTE M4HM87P-00/M4HM87P-00, BIOS F6 
> 12/10/2014
> [  202.634933]  88011ea03d68 8142dce5 88011ea03db8 
> 
> [  202.634934]  88011ea03da8 8107e496 0aa90002 
> 81e249a0
> [  202.634935]  81815637 82e7c280  
> 0004
> [  202.634936] Call Trace:
> [  202.634939]  
> [  202.634939]  [] dump_stack+0x67/0x92
> [  202.634941]  [] __warn+0xc6/0xe0
> [  202.634944]  [] ? _raw_spin_unlock_irq+0x27/0x50
> [  202.634945]  [] warn_slowpath_fmt+0x4a/0x50
> [  202.634946]  [] trace_hardirqs_on_caller+0x113/0x1b0
> [  202.634948]  [] trace_hardirqs_on+0xd/0x10
> [  202.634949]  [] _raw_spin_unlock_irq+0x27/0x50
> [  202.634951]  [] rtc_handler+0x32/0xa0
> [  202.634954]  [] acpi_ev_fixed_event_detect+0xd4/0xfb
> [  202.634956]  [] acpi_ev_sci_xrupt_handler+0xf/0x2d
> [  202.634957]  [] acpi_irq+0x11/0x2c
> [  202.634960]  [] __handle_irq_event_percpu+0x58/0x370
> [  202.634961]  [] handle_irq_event_percpu+0x1e/0x50
> [  202.634962]  [] handle_irq_event+0x34/0x60
> [  202.634963]  [] handle_fasteoi_irq+0xa6/0x170
> [  202.634966]  [] handle_irq+0x15/0x20
> [  202.634967]  [] do_IRQ+0x68/0x130
> [  202.634968]  [] common_interrupt+0x89/0x89
> [  202.634970]  
> [  202.634970]  [] ? mwait_idle+0x93/0x210
> [  202.634971]  [] ? mwait_idle+0x8a/0x210
> [  202.634972]  [] arch_cpu_idle+0xa/0x10
> [  202.634973]  [] default_idle_call+0x1e/0x30
> [  202.634974]  [] cpu_startup_entry+0x17c/0x1f0
> [  202.634976]  [] rest_init+0x127/0x130
> [  202.634978]  [] start_kernel+0x3f6/0x403
> [  202.634980]  [] x86_64_start_reservations+0x2a/0x2c
> [  202.634981]  [] x86_64_start_kernel+0x173/0x186
> [  202.634982] ---[ end trace 293c99618fa08d34 ]---
> 
> Cc: Gabriele Mazzotta 
> Cc: Alexandre Belloni 
> Fixes: 983bf1256edb ("rtc: cmos: Clear ACPI-driven alarms upon resume")
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/rtc/rtc-cmos.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
Applied, thanks.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 13/41] drm/i915: Reuse the active golden render state batch

[Chris Wilson]

The golden render state is constant, but we recreate the batch setting
it up for every new context. If we keep that batch in a volatile cache
we can safely reuse it whenever we need to initialise a new context. We
mark the pages as purgeable and use the shrinker to recover pages from
the batch whenever we face memory pressues, recreating that batch afresh
on the next new context.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_render_state.c | 184 +--
 drivers/gpu/drm/i915/i915_gem_render_state.h |   4 +-
 drivers/gpu/drm/i915/intel_engine_cs.c   |   5 +
 drivers/gpu/drm/i915/intel_lrc.c |   2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c  |   2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.h  |   3 +
 6 files changed, 129 insertions(+), 71 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_render_state.c 
b/drivers/gpu/drm/i915/i915_gem_render_state.c
index 217e0b58b930..9625e1a662ed 100644
--- a/drivers/gpu/drm/i915/i915_gem_render_state.c
+++ b/drivers/gpu/drm/i915/i915_gem_render_state.c
@@ -28,17 +28,19 @@
 #include "i915_drv.h"
 #include "intel_renderstate.h"
 
-struct render_state {
+struct intel_render_state {
const struct intel_renderstate_rodata *rodata;
struct i915_vma *vma;
-   u32 aux_batch_size;
-   u32 aux_batch_offset;
+   u32 batch_offset;
+   u32 batch_size;
+   u32 aux_offset;
+   u32 aux_size;
 };
 
 static const struct intel_renderstate_rodata *
-render_state_get_rodata(const struct drm_i915_gem_request *req)
+render_state_get_rodata(const struct intel_engine_cs *engine)
 {
-   switch (INTEL_GEN(req->i915)) {
+   switch (INTEL_GEN(engine->i915)) {
case 6:
return _null_state;
case 7:
@@ -63,29 +65,27 @@ render_state_get_rodata(const struct drm_i915_gem_request 
*req)
  */
 #define OUT_BATCH(batch, i, val)   \
do {\
-   if (WARN_ON((i) >= PAGE_SIZE / sizeof(u32))) {  \
-   ret = -ENOSPC;  \
-   goto err_out;   \
-   }   \
+   if ((i) >= PAGE_SIZE / sizeof(u32)) \
+   goto err;   \
(batch)[(i)++] = (val); \
} while(0)
 
-static int render_state_setup(struct render_state *so)
+static int render_state_setup(struct intel_render_state *so,
+ struct drm_i915_private *i915)
 {
-   struct drm_i915_private *dev_priv = to_i915(so->vma->vm->dev);
const struct intel_renderstate_rodata *rodata = so->rodata;
-   const bool has_64bit_reloc = INTEL_GEN(dev_priv) >= 8;
+   const bool has_64bit_reloc = INTEL_GEN(i915) >= 8;
+   struct drm_i915_gem_object *obj = so->vma->obj;
unsigned int i = 0, reloc_index = 0;
-   struct page *page;
+   unsigned int needs_clflush;
u32 *d;
int ret;
 
-   ret = i915_gem_object_set_to_cpu_domain(so->vma->obj, true);
+   ret = i915_gem_obj_prepare_shmem_write(obj, _clflush);
if (ret)
return ret;
 
-   page = i915_gem_object_get_dirty_page(so->vma->obj, 0);
-   d = kmap(page);
+   d = kmap_atomic(i915_gem_object_get_dirty_page(obj, 0));
 
while (i < rodata->batch_items) {
u32 s = rodata->batch[i];
@@ -95,10 +95,8 @@ static int render_state_setup(struct render_state *so)
s = lower_32_bits(r);
if (has_64bit_reloc) {
if (i + 1 >= rodata->batch_items ||
-   rodata->batch[i + 1] != 0) {
-   ret = -EINVAL;
-   goto err_out;
-   }
+   rodata->batch[i + 1] != 0)
+   goto err;
 
d[i++] = s;
s = upper_32_bits(r);
@@ -110,12 +108,20 @@ static int render_state_setup(struct render_state *so)
d[i++] = s;
}
 
+   if (rodata->reloc[reloc_index] != -1) {
+   DRM_ERROR("only %d relocs resolved\n", reloc_index);
+   goto err;
+   }
+
+   so->batch_offset = so->vma->node.start;
+   so->batch_size = rodata->batch_items * sizeof(u32);
+
while (i % CACHELINE_DWORDS)
OUT_BATCH(d, i, MI_NOOP);
 
-   so->aux_batch_offset = i * sizeof(u32);
+   so->aux_offset = i * sizeof(u32);
 
-   if (HAS_POOLED_EU(dev_priv)) {
+   if (HAS_POOLED_EU(i915)) {
/*
 * We always program 3x6 pool config but 

[Intel-gfx] [PATCH 22/41] drm/i915: Implement pwrite without struct-mutex

[Chris Wilson]

We only need struct_mutex within pwrite for a brief window where we need
to serialise with rendering and control our cache domains. Elsewhere we
can rely on the backing storage being pinned, and forgive userspace any
races against us.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem.c | 353 ++--
 1 file changed, 122 insertions(+), 231 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index ab119ea49634..ba311a104564 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1115,72 +1115,50 @@ i915_gem_pread_ioctl(struct drm_device *dev, void *data,
  * page faults in the source data
  */
 
-static inline int
-fast_user_write(struct io_mapping *mapping,
-   loff_t page_base, int page_offset,
-   char __user *user_data,
-   int length)
+static inline bool
+ggtt_write(struct io_mapping *mapping,
+  loff_t base, int offset,
+  char __user *user_data, int length)
 {
-   void __iomem *vaddr_atomic;
void *vaddr;
unsigned long unwritten;
 
-   vaddr_atomic = io_mapping_map_atomic_wc(mapping, page_base);
/* We can use the cpu mem copy function because this is X86. */
-   vaddr = (void __force*)vaddr_atomic + page_offset;
-   unwritten = __copy_from_user_inatomic_nocache(vaddr,
+   vaddr = (void __force *)io_mapping_map_atomic_wc(mapping, base);
+   unwritten = __copy_from_user_inatomic_nocache(vaddr + offset,
  user_data, length);
-   io_mapping_unmap_atomic(vaddr_atomic);
-   return unwritten;
-}
-
-static inline unsigned long
-slow_user_access(struct io_mapping *mapping,
-unsigned long page_base, int page_offset,
-char __user *user_data,
-unsigned long length, bool pwrite)
-{
-   void __iomem *ioaddr;
-   void *vaddr;
-   unsigned long unwritten;
-
-   ioaddr = io_mapping_map_wc(mapping, page_base, PAGE_SIZE);
-   /* We can use the cpu mem copy function because this is X86. */
-   vaddr = (void __force *)ioaddr + page_offset;
-   if (pwrite)
-   unwritten = __copy_from_user(vaddr, user_data, length);
-   else
-   unwritten = __copy_to_user(user_data, vaddr, length);
+   io_mapping_unmap_atomic(vaddr);
+   if (unwritten) {
+   vaddr = (void __force *)
+   io_mapping_map_wc(mapping, base, PAGE_SIZE);
+   unwritten = copy_from_user(vaddr + offset, user_data, length);
+   io_mapping_unmap(vaddr);
+   }
 
-   io_mapping_unmap(ioaddr);
return unwritten;
 }
 
 /**
  * This is the fast pwrite path, where we copy the data directly from the
  * user into the GTT, uncached.
- * @i915: i915 device private data
- * @obj: i915 gem object
+ * @obj: i915 GEM object
  * @args: pwrite arguments structure
- * @file: drm file pointer
  */
 static int
-i915_gem_gtt_pwrite_fast(struct drm_i915_private *i915,
-struct drm_i915_gem_object *obj,
-struct drm_i915_gem_pwrite *args,
-struct drm_file *file)
+i915_gem_gtt_pwrite_fast(struct drm_i915_gem_object *obj,
+const struct drm_i915_gem_pwrite *args)
 {
+   struct drm_i915_private *i915 = to_i915(obj->base.dev);
struct i915_ggtt *ggtt = >ggtt;
-   struct drm_device *dev = obj->base.dev;
-   struct i915_vma *vma;
struct drm_mm_node node;
-   uint64_t remain, offset;
-   char __user *user_data;
+   struct i915_vma *vma;
+   u64 remain, offset;
+   void __user *user_data;
int ret;
-   bool hit_slow_path = false;
 
-   if (i915_gem_object_is_tiled(obj))
-   return -EFAULT;
+   ret = mutex_lock_interruptible(>drm.struct_mutex);
+   if (ret)
+   return ret;
 
intel_runtime_pm_get(i915);
vma = i915_gem_object_ggtt_pin(obj, NULL, 0, 0,
@@ -1197,21 +1175,17 @@ i915_gem_gtt_pwrite_fast(struct drm_i915_private *i915,
if (IS_ERR(vma)) {
ret = insert_mappable_node(ggtt, , PAGE_SIZE);
if (ret)
-   goto out;
-
-   ret = i915_gem_object_pin_pages(obj);
-   if (ret) {
-   remove_mappable_node();
-   goto out;
-   }
+   goto out_unlock;
+   GEM_BUG_ON(!node.allocated);
}
 
ret = i915_gem_object_set_to_gtt_domain(obj, true);
if (ret)
goto out_unpin;
 
+   mutex_unlock(>drm.struct_mutex);
+
intel_fb_obj_invalidate(obj, ORIGIN_CPU);
-   obj->mm.dirty = true;
 
user_data = u64_to_user_ptr(args->data_ptr);
offset =