Tim Gore
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ
> -Original Message-
> From: Arun Siluvery [mailto:arun.siluv...@linux.intel.com]
> Sent: Friday, June 10, 2016 7:30 AM
> To: Gore, Tim; intel-gfx@lists.freedesktop.org
> Subject: Re: [PATCH v2] drm/
On Jun 09 Zanoni, Paulo R wrote:
> Em Qui, 2016-06-09 às 11:58 -0400, Lyude escreveu:
> > From https://bugs.freedesktop.org/show_bug.cgi?id=96461 :
> >
> > This was kind of a difficult bug to track down. If you're using a
> > Haswell system running GNOME and you have fbc completely enabled and
> >
The failed test case is related to the following bug:
https://bugs.freedesktop.org/show_bug.cgi?id=95372
> -Original Message-
> From: Patchwork [mailto:patchw...@emeril.freedesktop.org]
> Sent: Friday, June 10, 2016 8:32 AM
> To: Wang, Zhi A
> Cc: intel-gfx@lists.freedesktop.org
> Subject
On 09/06/2016 20:19, tim.g...@intel.com wrote:
From: Tim Gore
This patch enables a workaround for a mid thread preemption
issue where a hardware timing problem can prevent the
context restore from happening, leading to a hang.
v2: move to gen9_init_workarounds (Arun)
Signed-off-by: Tim Gore
== Series Details ==
Series: SKL watermark fixes for !fbcon
URL : https://patchwork.freedesktop.org/series/8513/
State : failure
== Summary ==
Series 8513v1 SKL watermark fixes for !fbcon
http://patchwork.freedesktop.org/api/1.0/series/8513/revisions/1/mbox
Test gem_exec_flush:
Subgro
== Series Details ==
Series: Enable FBC on SKL (rev5)
URL : https://patchwork.freedesktop.org/series/4722/
State : success
== Summary ==
Series 4722v5 Enable FBC on SKL
http://patchwork.freedesktop.org/api/1.0/series/4722/revisions/5/mbox
Test kms_flip:
Subgroup basic-flip-vs-wf_vblan
== Series Details ==
Series: Introduce the implementation of GVT context (rev8)
URL : https://patchwork.freedesktop.org/series/7208/
State : failure
== Summary ==
Series 7208v8 Introduce the implementation of GVT context
http://patchwork.freedesktop.org/api/1.0/series/7208/revisions/8/mbox
Te
Hi Thierry,
2016년 06월 08일 00:26에 Thierry Reding 이(가) 쓴 글:
> From: Thierry Reding
>
> Move the modeset locking from drivers into FB helpers.
>
> Signed-off-by: Thierry Reding
> ---
> drivers/gpu/drm/drm_fb_helper.c| 59
> +-
> drivers/gpu/drm/i915/intel
It's possible to have a non-zero plane mask and still wind up with a
total data rate of zero. There are two cases where this can happen:
* planes are active (from the KMS point of view), but are
all fully clipped (positioned offscreen)
* the only active plane on a CRTC is the cursor (which i
intel_state->active_crtcs is usually only initialized when doing a
modeset. During our first atomic commit after boot, we're effectively
faking a modeset to sanitize the DDB/wm setup, so ensure that this field
gets initialized before use.
Reported-by: Tvrtko Ursulin
Cc: Tvrtko Ursulin
Signed-of
When we sanitize our DDB and watermark info during the first atomic
commit, we need to calculate the total data rate. Since we haven't
explicitly added the planes for each CRTC to our atomic state, the total
data rate calculation will try to use the cached values from a previous
commit (which are
There are a handful of watermark bugs that are only triggered (or more easily
triggered) when running without fbcon. Thanks Tvrtko for pointing these out.
I do still see some WARN()'s from other parts of the display code when
launching X in a non-fbcon setup, so there may be other bugfixes needed
On Fri, Jun 03, 2016 at 05:59:11PM +0300, Ville Syrjälä wrote:
> On Fri, Jun 03, 2016 at 03:36:49PM +0100, Chris Wilson wrote:
> > When trying to split up the initialisation phase and the registration
> > phase, one immediate problem encountered is trying to use our own i2c
> > devices before regis
Em Qui, 2016-06-09 às 11:58 -0400, Lyude escreveu:
> From https://bugs.freedesktop.org/show_bug.cgi?id=96461 :
>
> This was kind of a difficult bug to track down. If you're using a
> Haswell system running GNOME and you have fbc completely enabled and
> working, playing videos can result in video
From: Chris Wilson
... instead of the previous ORIGIN_GTT. This should actually
invalidate FBC once something is written on the frontbuffer using WC
mmaps. The problem with ORIGIN_GTT is that the automatic hardware
tracking is not able to detect the WC writes as it can detect the GTT
writes.
Thi
This patch introduces an approach to track the execlist context status
change.
GVT-g uses GVT context as the "shadow context". The content inside GVT
context will be copied back to guest after the context is idle. And GVT-g
has to know the status of the execlist context.
This function is configur
v5:
- Let functions take struct drm_i915_private *. (Tvrtko)
- Fold vGPU related active check into the inner functions. (Kevin)
Reviewed-by: Tvrtko Ursulin
Reviewed-by: Joonas Lahtinen
Suggested-by: Kevin Tian
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
Cc: Kevin Tian
Signed-off-by: Zhi Wang
--
This patch introduces an option for configuring the ring buffer size
of a LRC context after the context creation.
v9:
- Fix an identation issue. (Chris)
v8:
- Rename the data member in i915_gem_context. (Chris)
Reviewed-by: Joonas Lahtinen
Cc: Joonas Lahtinen
Cc: Chris Wilson
Signed-off-by: Z
This patch introduces the support of LRC context single submission.
As GVT context may come from different guests, which require different
configuration of render registers. It can't be combined into a dual ELSP
submission combo.
Only GVT-g will create this kinds of GEM context currently.
v8:
-
GVT workload scheduler needs special host LRC contexts, the so called
"shadow LRC context" to submit guest workload to host i915. During the
guest workload submission, workload scheduler fills the shadow LRC
context with the content of guest LRC context: engine context is copied
without changes, ri
From: Bing Niu
This patch introduces host graphics memory partition when GVT-g
is enabled.
Under GVT-g, i915 host driver only owned limited graphics resources,
others are managed by GVT-g resource allocator and kept for other vGPUs.
v7:
- Add comments about low/high GM size for host. (Joonas)
Currently the addressing mode bit in context descriptor is statically
generated from the configuration of system-wide PPGTT usage model.
GVT-g will load the PPGTT shadow page table by itself and probably one
guest is using a different addressing mode with i915 host. The addressing
mode bits of a L
To get the offset of the members in PVINFO page, offsetof() looks much
better than the tricky approach in current code.
v7:
- Move "offsetof()" modification into a dedicated patch. (Joonas)
Suggested-by: Joonas Lahtinen
Reviewed-by: Joonas Lahtinen
Cc: Joonas Lahtinen
Signed-off-by: Zhi Wang
This patch introduces the very basic framework of GVT-g device model,
includes basic prototypes, definitions, initialization.
v8:
- Remove the GVT idr and mutex in intel_gvt_host. (Joonas)
v7:
- Refine the URL link in Kconfig. (Joonas)
- Refine the introduction of GVT-g host support in Kconfig. (
As the PVINFO page definition is used by both GVT-g guest (vGPU) and GVT-g
host (GVT-g kernel device model), factor it out for better code structure.
v7:
- Split the "offsetof" modification into a dedicated patch. (Joonas)
v3:
- Use offsetof to calculate the member offset of PVINFO structure (Joo
This patchset introduces the implementation of GVT context. GVT
context is a special GEM context used by GVT-g. GVT-g uses it as the shadow
context.It doesn't have a drm client nor a PPGTT. And it requires a larger
ring buffer with several special features need by GVT-g workload scheduler
like cont
On 9 June 2016 at 15:49, Zanoni, Paulo R wrote:
> Em Qua, 2016-06-08 às 22:35 +0100, Steven Honeyman escreveu:
>> Hi,
>
> Hi
>
> CC'ing the mailing list.
>
>>
>> With commit a98ee79317b4091cafb502b4ffdbbbe1335e298c to enable FBC by
>> default, I get a strange issue with screen update/refresh (sorr
On 07/06/2016 12:17, Maarten Lankhorst wrote:
Op 01-06-16 om 19:07 schreef john.c.harri...@intel.com:
From: John Harrison
The purpose of this patch series is to convert the requst structure to
use fence objects for the underlying completion tracking. The fence
object requires a sequence number
On Wed, Jun 8, 2016 at 12:18 PM, Dave Gordon wrote:
> On 08/06/16 09:40, Daniel Vetter wrote:
>>
>> On Wed, Jun 08, 2016 at 01:57:44PM +0530, Akshu Agrawal wrote:
>>>
>>> CHV pipe C hits underrun when we get -ve X values of cursor. To avoid
>>> this we crop the cursor image for by -ve X value and
This reverts commit f165d2834ceb3d5c29bebadadc27629bebf402ac.
It breaks one of our CI systems. Quoting from Ville:
[ 13.100979] [drm:ironlake_init_pch_refclk] has_panel 1 has_lvds 1 has_ck505
0 using_ssc_source 1
[ 13.101413] [ cut here ]
[ 13.101429] kernel BUG at
== Series Details ==
Series: i915/fbc: Disable on HSW by default for now
URL : https://patchwork.freedesktop.org/series/8503/
State : warning
== Summary ==
Series 8503v1 i915/fbc: Disable on HSW by default for now
http://patchwork.freedesktop.org/api/1.0/series/8503/revisions/1/mbox
Test kms_
On 02/06/2016 11:28, Tvrtko Ursulin wrote:
On 01/06/16 18:07, john.c.harri...@intel.com wrote:
From: John Harrison
The purpose of this patch series is to convert the requst structure to
use fence objects for the underlying completion tracking. The fence
object requires a sequence number. The
From https://bugs.freedesktop.org/show_bug.cgi?id=96461 :
This was kind of a difficult bug to track down. If you're using a
Haswell system running GNOME and you have fbc completely enabled and
working, playing videos can result in video artifacts. Steps to
reproduce:
- Run GNOME
- Ensure FBC is e
https://paste.fedoraproject.org/376691/
On 9 June 2016 at 16:22, Chris Wilson wrote:
> On Thu, Jun 09, 2016 at 04:02:26PM +0100, Matthew Auld wrote:
>> Well, at least for me having the global forcewake produces a kernel
>> warning during the suspend-resume test case.
>
> If userspace can trigger
On Thu, Jun 09, 2016 at 04:02:26PM +0100, Matthew Auld wrote:
> Well, at least for me having the global forcewake produces a kernel
> warning during the suspend-resume test case.
If userspace can trigger a kernel warning, we fix the kernel...
Except this is debugfs, and if necessary we can caveat
== Series Details ==
Series: drm/i915/gen9: implement WaConextSwitchWithConcurrentTLBInvalidate
(rev2)
URL : https://patchwork.freedesktop.org/series/8487/
State : warning
== Summary ==
Series 8487v2 drm/i915/gen9: implement WaConextSwitchWithConcurrentTLBInvalidate
http://patchwork.freedeskt
Well, at least for me having the global forcewake produces a kernel
warning during the suspend-resume test case.
On 9 June 2016 at 15:53, Chris Wilson wrote:
> On Thu, Jun 09, 2016 at 03:33:47PM +0100, Matthew Auld wrote:
>> We shouldn't be holding the forcewake whilst going through suspend-resum
On Thu, Jun 09, 2016 at 03:33:47PM +0100, Matthew Auld wrote:
> We shouldn't be holding the forcewake whilst going through suspend-resume
> cycle
Why not? That's legal behaviour, the kernel should be restoring the user
forcewake setting and there should be igt for that already - otherwise
we have
From: Tim Gore
This patch enables a workaround for a mid thread preemption
issue where a hardware timing problem can prevent the
context restore from happening, leading to a hang.
v2: move to gen9_init_workarounds (Arun)
Signed-off-by: Tim Gore
---
drivers/gpu/drm/i915/i915_reg.h | 4
Em Qua, 2016-06-08 às 22:35 +0100, Steven Honeyman escreveu:
> Hi,
Hi
CC'ing the mailing list.
>
> With commit a98ee79317b4091cafb502b4ffdbbbe1335e298c to enable FBC by
> default, I get a strange issue with screen update/refresh (sorry if
> my
> terminology is off - I'm not a graphics dev!).
>
We shouldn't be holding the forcewake whilst going through suspend-resume
cycle, so instead of globally holding the forcewake we reduce this to
when we actually need to read the registers.
Cc: Chris Wilson
Signed-off-by: Matthew Auld
---
tests/gem_workarounds.c | 7 ---
1 file changed, 4 in
On Thu, Jun 09, 2016 at 04:31:25PM +0300, Joonas Lahtinen wrote:
> On to, 2016-06-09 at 12:29 +0100, Chris Wilson wrote:
> > With in the introduction of the reloc page cache, we are just one step
> > away from refactoring the relocation write functions into one. Not only
> > does it tidy the code (
On Thu, Jun 09, 2016 at 04:51:41PM +0300, Joonas Lahtinen wrote:
> On to, 2016-06-09 at 14:35 +0100, Chris Wilson wrote:
> > On Thu, Jun 09, 2016 at 04:06:59PM +0300, Joonas Lahtinen wrote:
> > >
> > > On to, 2016-06-09 at 12:29 +0100, Chris Wilson wrote:
> > > >
> > > > There is an improbable, b
On to, 2016-06-09 at 14:35 +0100, Chris Wilson wrote:
> On Thu, Jun 09, 2016 at 04:06:59PM +0300, Joonas Lahtinen wrote:
> >
> > On to, 2016-06-09 at 12:29 +0100, Chris Wilson wrote:
> > >
> > > There is an improbable, but not impossible, case that if we leave the
> > > pages unpin as we operate
Tim Gore
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ
> -Original Message-
> From: Arun Siluvery [mailto:arun.siluv...@linux.intel.com]
> Sent: Thursday, June 09, 2016 2:05 PM
> To: Gore, Tim; intel-gfx@lists.freedesktop.org
> Subject: Re: [PATCH] drm/i
On Thu, Jun 09, 2016 at 04:06:59PM +0300, Joonas Lahtinen wrote:
> On to, 2016-06-09 at 12:29 +0100, Chris Wilson wrote:
> > There is an improbable, but not impossible, case that if we leave the
> > pages unpin as we operate on the object, then somebody may steal the
> > lock and change the cache d
On to, 2016-06-09 at 12:29 +0100, Chris Wilson wrote:
> With in the introduction of the reloc page cache, we are just one step
> away from refactoring the relocation write functions into one. Not only
> does it tidy the code (slightly), but it greatly simplifies the control
> logic much to gcc's sa
On to, 2016-06-09 at 12:29 +0100, Chris Wilson wrote:
> Since we know the write domain, we can drop the local variable and make
> the code look a tiny bit simpler.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
> ---
> drivers/gpu/drm/i915/i915_gem.c | 15 ---
> 1 fi
On to, 2016-06-09 at 12:29 +0100, Chris Wilson wrote:
> There is an improbable, but not impossible, case that if we leave the
> pages unpin as we operate on the object, then somebody may steal the
> lock and change the cache domains after we have already inspected them.
>
Which lock exactly?
> (
On 09/06/2016 13:48, tim.g...@intel.com wrote:
From: Tim Gore
This patch enables a workaround for a mid thread preemption
issue where a hardware timing problem can prevent the
context restore from happening, leading to a hang.
Signed-off-by: Tim Gore
---
drivers/gpu/drm/i915/i915_gem_gtt.c
On to, 2016-06-09 at 12:29 +0100, Chris Wilson wrote:
> If we quickly switch from writing through the GTT to a read of the
> physical page directly with the CPU (e.g. performing relocations through
> the GTT and then running the command parser), we can observe that the
> writes are not visible to t
On to, 2016-06-09 at 12:29 +0100, Chris Wilson wrote:
> If we want to read the pages directly via the CPU, we have to be sure
> that we have to flush the writes via the GTT (as the CPU can not see
> the address aliasing).
>
> Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
> ---
> dr
On to, 2016-06-09 at 12:29 +0100, Chris Wilson wrote:
> This is a companion to i915_gem_obj_prepare_shmem_read() that prepares
> the backing storage for direct writes. It first serialises with the GPU,
> pins the backing storage and then indicates what clfushes are required in
> order for the write
On to, 2016-06-09 at 12:29 +0100, Chris Wilson wrote:
> It is useful when looking at captured error states to check the recorded
> BBADDR register (the address of the last batchbuffer instruction loaded)
> against the expected offset of the batch buffer, and so do a quick check
> that (a) the captu
On to, 2016-06-09 at 12:29 +0100, Chris Wilson wrote:
> When doing relocations, we have to obtain a mapping to the page
> containing the target address. This is either a kmap or iomap depending
> on GPU and its cache coherency. Neighbouring relocation entries are
> typically within the same page an
Use distinctive name for cpu_hotplug.dep_map to avoid the actual
cpu_hotplug.lock appearing as cpu_hotplug.lock#2 in lockdep splats.
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Gautham R. Shenoy
Cc: intel-gfx@lists.freedesktop.org
Cc: triv...@kernel.org
Acked-by: Gautham R. Shenoy
Signed-off-by: Jo
== Series Details ==
Series: series starting with [1/8] drm/i915: Print the batchbuffer offset next
to BBADDR in error state
URL : https://patchwork.freedesktop.org/series/8491/
State : failure
== Summary ==
Applying: drm/i915: Print the batchbuffer offset next to BBADDR in error state
fatal:
On Thu, Jun 09, 2016 at 12:29:34PM +0100, Chris Wilson wrote:
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index a41fa01eb024..c6d06cb21191 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -563,34 +563,95 @@ __copy_fro
This will make it more likely that intermediary watermarks cause fifo
underruns, which is useful when writing watermark specific tests,
to make it more likely to trigger FIFO underruns in intermediary watermarks.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_params.c | 1 +
dr
On Thu, Jun 09, 2016 at 12:29:36PM +0100, Chris Wilson wrote:
> If we quickly switch from writing through the GTT to a read of the
> physical page directly with the CPU (e.g. performing relocations through
> the GTT and then running the command parser), we can observe that the
> writes are not visi
tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc
head: ae4df11a0f538b83781cf120a78dde32b0070600
commit: ae4df11a0f538b83781cf120a78dde32b0070600 [11/11] drm: Move
format-related helpers to drm_fourcc.c
reproduce: make htmldocs
All warnings (new ones prefixed by >>):
drivers/gp
There is an improbable, but not impossible, case that if we leave the
pages unpin as we operate on the object, then somebody may steal the
lock and change the cache domains after we have already inspected them.
(Whilst here, avail ourselves of the opportunity to take a couple of
steps to make the
This is a companion to i915_gem_obj_prepare_shmem_read() that prepares
the backing storage for direct writes. It first serialises with the GPU,
pins the backing storage and then indicates what clfushes are required in
order for the writes to be coherent.
Whilst here, fix support for ancient CPUs w
If we want to read the pages directly via the CPU, we have to be sure
that we have to flush the writes via the GTT (as the CPU can not see
the address aliasing).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/dr
Just a small set of changes after the last 100 or so that start
preparing for an overhaul of execbuf relocation processing - though
immediately after these in my queue are partial VMA handling...
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesk
If we quickly switch from writing through the GTT to a read of the
physical page directly with the CPU (e.g. performing relocations through
the GTT and then running the command parser), we can observe that the
writes are not visible to the CPU. It is not a coherency problem, as
extensive investigat
It is useful when looking at captured error states to check the recorded
BBADDR register (the address of the last batchbuffer instruction loaded)
against the expected offset of the batch buffer, and so do a quick check
that (a) the capture is true or (b) HEAD hasn't wandered off into the
badlands.
Since we know the write domain, we can drop the local variable and make
the code look a tiny bit simpler.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers
With in the introduction of the reloc page cache, we are just one step
away from refactoring the relocation write functions into one. Not only
does it tidy the code (slightly), but it greatly simplifies the control
logic much to gcc's satisfaction.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm
When doing relocations, we have to obtain a mapping to the page
containing the target address. This is either a kmap or iomap depending
on GPU and its cache coherency. Neighbouring relocation entries are
typically within the same page and so we can cache our kmapping between
them and avoid those pe
On 07/06/16 09:41, Tvrtko Ursulin wrote:
On 07/06/16 09:14, Dave Gordon wrote:
The last stage of the GuC loader also sanitises the GuC submission
settings, so should be called unconditionally (even on platforms
without a GuC) to ensure consistent settings; in particular, this
prevents any atte
tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc
head: ae4df11a0f538b83781cf120a78dde32b0070600
commit: ed4f885657fe7e9bfec3d86a2b426da1e0d0c5de [7/11] drm/arc: Nuke event_list
config: x86_64-randconfig-s5-06091636 (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 2016043
> -Original Message-
> From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
> Sent: Thursday, June 09, 2016 1:45 PM
> To: Wang, Zhi A ; intel-gfx@lists.freedesktop.org
> Cc: ch...@chris-wilson.co.uk; Lv, Zhiyuan ; Tian, Kevin
> ; tvrtko.ursu...@linux.intel.com
> Subject: Re: [PA
On to, 2016-06-09 at 03:34 -0400, Zhi Wang wrote:
> Currently the addressing mode bit in context descriptor is statically
> generated from the configuration of system-wide PPGTT usage model.
>
> GVT-g will load the PPGTT shadow page table by itself and probably one
> guest is using a different add
On to, 2016-06-09 at 03:34 -0400, Zhi Wang wrote:
> This patch introduces an approach to track the execlist context status
> change.
>
> GVT-g uses GVT context as the "shadow context". The content inside GVT
> context will be copied back to guest after the context is idle. And GVT-g
> has to know
On Thu, 2016-06-09 at 11:02 +0300, Ville Syrjälä wrote:
> On Mon, Jun 06, 2016 at 04:29:07PM +0300, Mika Kahola wrote:
> > Helper routine to read out maximum supported bits per
> > component for DisplayPort legay converters.
> >
> > Signed-off-by: Mika Kahola
> > ---
> > drivers/gpu/drm/drm_dp_h
Hi:
As this series are not related to display subsystem, according to Joonas'
suggestion, I opened a new bug:
Bug 96448 - [BDW]igt@kms_pipe_crc_basic@suspend-read-crc-pipe-? cause dmesg
warn
https://bugs.freedesktop.org/show_bug.cgi?id=96448
Thanks,
Zhi.
> -Original Message-
> From:
Somehow threading seems to be broken, v2 of 6/6 is applied out of order
after 1/6. Also I can't see v2 of 2/6 and v2 of 4/6 at [1] which I sent
along with v2 of 6/6. AFAICS the In-reply-to fields were correct in the
v2 versions I sent.
--Imre
[1] https://patchwork.freedesktop.org/series/8414/
>
On 08/06/16 13:20, ankitprasad.r.sha...@intel.com wrote:
From: Ankitprasad Sharma
In pwrite_fast, map an object page by page if obj_ggtt_pin fails. First,
we try a nonblocking pin for the whole object (since that is fastest if
reused), then failing that we try to grab one page in the mappable
== Series Details ==
Series: drm/i915/gen9: implement WaConextSwitchWithConcurrentTLBInvalidate
URL : https://patchwork.freedesktop.org/series/8487/
State : success
== Summary ==
Series 8487v1 drm/i915/gen9: implement WaConextSwitchWithConcurrentTLBInvalidate
http://patchwork.freedesktop.org/a
Tim Gore
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ
> -Original Message-
> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
> Sent: Thursday, June 09, 2016 9:34 AM
> To: Gore, Tim; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATC
On Thu, Jun 09, 2016 at 11:31:20AM +0300, Jani Nikula wrote:
> On Thu, 09 Jun 2016, Dhinakaran Pandiyan
> wrote:
> > IGT vblank tests fail on CHV by timing out on VBIs if PSR is enabled. We
> > do not get VBIs as the source timing generation is disabled when PSR is
> > active. The first two patch
On Thu, 09 Jun 2016, tim.g...@intel.com wrote:
> From: Tim Gore
>
> This patch enables a workaround for a mid thread preemption
> issue where a hardware timing problem can prevent the
> context restore from happening, leading to a hang.
>
> Signed-off-by: Tim Gore
> ---
> drivers/gpu/drm/i915/i9
On 07/06/16 13:48, Boris Brezillon wrote:
We have a 1:1 relationship between connectors and encoders and the
driver is relying on the atomic helpers: we can drop the custom
->best_encoder() implementation and let the core call
drm_atomic_helper_best_encoder() for us.
Signed-off-by: Boris Brezi
> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> Sent: Thursday, June 9, 2016 11:14 AM
> To: Kahola, Mika
> Cc: dri-de...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org;
> jim.br...@linux.intel.com; daniel.vet...@ffwll.ch
> Subject: Re: [PATCH v
On Thu, 09 Jun 2016, Dhinakaran Pandiyan wrote:
> IGT vblank tests fail on CHV by timing out on VBIs if PSR is enabled. We
> do not get VBIs as the source timing generation is disabled when PSR is
> active. The first two patches written by Rodrigo add drm hooks. Patch 3
> deactivates PSR when VBI
From: Tim Gore
This patch enables a workaround for a mid thread preemption
issue where a hardware timing problem can prevent the
context restore from happening, leading to a hang.
Signed-off-by: Tim Gore
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 6 ++
drivers/gpu/drm/i915/i915_reg.h |
On Mon, Jun 06, 2016 at 04:29:11PM +0300, Mika Kahola wrote:
> Filter out a mode that exceeds the max pixel rate setting
> for DP to VGA dongle. This is defined in DPCD register 0x81
> if detailed cap info i.e. info field is 4 bytes long and
> it is available for DP downstream port.
>
> The regist
On Mon, Jun 06, 2016 at 04:29:07PM +0300, Mika Kahola wrote:
> Helper routine to read out maximum supported bits per
> component for DisplayPort legay converters.
>
> Signed-off-by: Mika Kahola
> ---
> drivers/gpu/drm/drm_dp_helper.c | 31 +++
> include/drm/drm_dp_hel
== Series Details ==
Series: Introduce the implementation of GVT context (rev7)
URL : https://patchwork.freedesktop.org/series/7208/
State : warning
== Summary ==
Series 7208v7 Introduce the implementation of GVT context
http://patchwork.freedesktop.org/api/1.0/series/7208/revisions/7/mbox
Te
On Mon, Jun 06, 2016 at 04:29:06PM +0300, Mika Kahola wrote:
> Helper routine to read out maximum supported pixel rate
> for DisplayPort legay VGA converter or TMDS clock rate
> for other digital legacy converters. The helper returns
> clock rate in kHz.
>
> Signed-off-by: Mika Kahola
> ---
> dr
On Mon, Jun 06, 2016 at 04:29:05PM +0300, Mika Kahola wrote:
> Helper routine to read out DisplayPort branch device type. The spec
> defines these type as following
>
> 0 DisplayPort
> 1 Analog VGA
> 2 DVI
> 3 HDMI
> 4 Others without EDID support
> 5
On Mon, Jun 06, 2016 at 04:29:04PM +0300, Mika Kahola wrote:
> Read DisplayPort downstream port capabilities. Depending on
> the DP port the capabilities are defined in length of 1 byte
> or 4 bytes depending if the detailed capability information is
> available.
>
> Signed-off-by: Mika Kahola
>
As the PVINFO page definition is used by both GVT-g guest (vGPU) and GVT-g
host (GVT-g kernel device model), factor it out for better code structure.
v7:
- Split the "offsetof" modification into a dedicated patch. (Joonas)
v3:
- Use offsetof to calculate the member offset of PVINFO structure (Joo
This patch introduces an approach to track the execlist context status
change.
GVT-g uses GVT context as the "shadow context". The content inside GVT
context will be copied back to guest after the context is idle. And GVT-g
has to know the status of the execlist context.
This function is configur
Currently the addressing mode bit in context descriptor is statically
generated from the configuration of system-wide PPGTT usage model.
GVT-g will load the PPGTT shadow page table by itself and probably one
guest is using a different addressing mode with i915 host. The addressing
mode bits of a L
From: Bing Niu
This patch introduces host graphics memory partition when GVT-g
is enabled.
Under GVT-g, i915 host driver only owned limited graphics resources,
others are managed by GVT-g resource allocator and kept for other vGPUs.
v7:
- Add comments about low/high GM size for host. (Joonas)
This patch introduces the very basic framework of GVT-g device model,
includes basic prototypes, definitions, initialization.
v8:
- Remove the GVT idr and mutex in intel_gvt_host. (Joonas)
v7:
- Refine the URL link in Kconfig. (Joonas)
- Refine the introduction of GVT-g host support in Kconfig. (
v5:
- Let functions take struct drm_i915_private *. (Tvrtko)
- Fold vGPU related active check into the inner functions. (Kevin)
Reviewed-by: Tvrtko Ursulin
Reviewed-by: Joonas Lahtinen
Suggested-by: Kevin Tian
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
Cc: Kevin Tian
Signed-off-by: Zhi Wang
--
This patch introduces the support of LRC context single submission.
As GVT context may come from different guests, which require different
configuration of render registers. It can't be combined into a dual ELSP
submission combo.
Only GVT-g will create this kinds of GEM context currently.
v8:
-
1 - 100 of 104 matches
Mail list logo
