On Wed, 2016-04-13 at 11:18 +0200, Maarten Lankhorst wrote:
> Re-use unpin_work->pending, but also set vblank count before
> intel_mark_page_flip_active to be sure.
Be sure of what?
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 11 ++-
> drivers/gp
== Series Details ==
Series: pwm: add support for atomic update (rev2)
URL : https://patchwork.freedesktop.org/series/5071/
State : failure
== Summary ==
Series 5071v2 pwm: add support for atomic update
http://patchwork.freedesktop.org/api/1.0/series/5071/revisions/2/mbox/
Test kms_pipe_crc_b
Ben Widawsky writes:
> [ text/plain ]
> On Thu, Apr 14, 2016 at 07:48:13AM -0700, Ben Widawsky wrote:
>> On Thu, Apr 14, 2016 at 11:14:48AM +0300, Jani Nikula wrote:
>> > On Thu, 14 Apr 2016, Jani Nikula wrote:
>> > > On Wed, 13 Apr 2016, Ben Widawsky wrote:
>> > >> The two behavioral changes h
On Thursday 14 April 2016 19:20:22 Ville Syrjälä wrote:
> On Wed, Apr 13, 2016 at 05:07:04PM -, Patchwork wrote:
> > == Series Details ==
> >
> > Series: drm/i915: Fix eDP low vswing for Broadwell (rev3)
> > URL : https://patchwork.freedesktop.org/series/4499/
> > State : failure
> >
> > ==
Mika Kuoppala writes:
> [ text/plain ]
> ville.syrj...@linux.intel.com writes:
>
>> [ text/plain ]
>> From: Ville Syrjälä
>>
>> On VLV/CHV the master interrupt enable bit only affects GT/PM
>> interrupts. Display interrupts are not affected by the master
>> irq control.
>>
>> Also it seems that
On Thu, Apr 14, 2016 at 10:48:15AM -0700, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Replace the legacy drm_send_vblank_event() with the new helper function.
>
> Signed-off-by: Gustavo Padovan
Applied to drm-intel.git, thanks.
-Daniel
> ---
> drivers/gpu/drm/i915/intel_display.c | 6
== Series Details ==
Series: series starting with [V2,1/3] PSR status on sysfs interface
URL : https://patchwork.freedesktop.org/series/5750/
State : success
== Summary ==
Series 5750v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/5750/revisions/1/mbox/
bdw-ult
From: Tim Gore
This is a re-send of patch 3/3 from Arun Siluvery's patch
series "Add Pooled EU support to BXT", originally submitted
20 July 2015. Patches 1 and 2 are already merged in preparation.
This final patch actually enables the feature. The rest of this
commit message is taken from the or
== Series Details ==
Series: drm/i915/bxt: PORT_PLL_REF_SEL bit should be set for all BXT variations.
URL : https://patchwork.freedesktop.org/series/5751/
State : success
== Summary ==
Series 5751v1 drm/i915/bxt: PORT_PLL_REF_SEL bit should be set for all BXT
variations.
http://patchwork.free
On 14/04/16 17:37, Patchwork wrote:
== Series Details ==
Series: series starting with [1/3] drm/i915: Use readl/writel for ring buffer
access
URL : https://patchwork.freedesktop.org/series/5714/
State : failure
== Summary ==
Series 5714v1 Series without cover letter
http://patchwork.freede
Do not use magic numbers, do not prefix stuff with "PCI_", do not
declare registers in implementation files. Also move the PCI
registers under correct comment in i915_reg.h.
Cc: Jani Nikula
Cc: Chris Wilson
Cc: Ville Syrjälä
Signed-off-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_dma.c
Thanks for tidying up and pushing.
Peter.
On Thu, 14 Apr 2016, Chris Wilson wrote:
On Wed, Apr 13, 2016 at 03:03:25PM +0100, Chris Wilson wrote:
From: Peter Antoine
Allow for the MOCS to be programmed for all engines.
Currently we program the MOCS when the first render batch
goes through. Th
From: Tvrtko Ursulin
Recent refactoring has made absence of snd-hda-intel a test
failure do the respective modprobe being at the end of a
reload function now.
Only fail in this case if module was previously unloaded.
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
---
tests/drv_module_reload_
== Series Details ==
Series: drm/i915:bxt: Enable Pooled EU support (rev2)
URL : https://patchwork.freedesktop.org/series/5725/
State : failure
== Summary ==
Series 5725v2 drm/i915:bxt: Enable Pooled EU support
http://patchwork.freedesktop.org/api/1.0/series/5725/revisions/2/mbox/
Test gem_sy
On 13/04/16 16:12, Chris Wilson wrote:
On Wed, Apr 13, 2016 at 03:47:58PM +0100, Chris Wilson wrote:
+ /* We also want to clear any cached iomaps as they wrap vmap */
+ list_for_each_entry_safe(vma, next,
+&dev_priv->ggtt.base.inactive_list, vm_link)
== Series Details ==
Series: drm/i915: Clean up PCI config register handling
URL : https://patchwork.freedesktop.org/series/5768/
State : failure
== Summary ==
Series 5768v1 drm/i915: Clean up PCI config register handling
http://patchwork.freedesktop.org/api/1.0/series/5768/revisions/1/mbox/
When moving the call to gem_set_tiling into the subtests, the one needed
by addfb25-framebuffer-vs-set-tiling was left out.
Signed-off-by: Tomeu Vizoso
---
tests/kms_addfb_basic.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tests/kms_addfb_basic.c b/tests/kms_addfb_basic.c
index 30f31229
On Fri, Apr 15, 2016 at 10:40:42AM +0100, Tvrtko Ursulin wrote:
>
> On 13/04/16 16:12, Chris Wilson wrote:
> >On Wed, Apr 13, 2016 at 03:47:58PM +0100, Chris Wilson wrote:
> >>+ /* We also want to clear any cached iomaps as they wrap vmap */
> >>+ list_for_each_entry_safe(vma, next,
> >>+
On 14/04/16 18:19, Dave Gordon wrote:
With the new i915_gem_obj_pin_map() interface, it makes sense to keep
GuC objects (which are always pinned in memory and in the GGTT anyway)
mapped into kernel address space, rather than mapping and unmapping them
on each access.
This preliminary patch sets
On 14/04/16 18:19, Dave Gordon wrote:
From: Alex Dai
Now that we keep GuC shared objects mapped into kernel space for their
entire lifetime, we can simplify the code for accessing the doorbells
and work queue, which were previously calling kmap_atomic() on *each*
request submission.
This patc
On Fri, Apr 15, 2016 at 10:19:32AM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Recent refactoring has made absence of snd-hda-intel a test
> failure do the respective modprobe being at the end of a
> reload function now.
>
> Only fail in this case if module was previously unloaded.
>
On Fri, Apr 15, 2016 at 12:17:18PM +0300, Joonas Lahtinen wrote:
> Do not use magic numbers, do not prefix stuff with "PCI_", do not
> declare registers in implementation files. Also move the PCI
> registers under correct comment in i915_reg.h.
>
> Cc: Jani Nikula
> Cc: Chris Wilson
> Cc: Ville
On 15/04/16 11:00, Chris Wilson wrote:
On Fri, Apr 15, 2016 at 10:40:42AM +0100, Tvrtko Ursulin wrote:
On 13/04/16 16:12, Chris Wilson wrote:
On Wed, Apr 13, 2016 at 03:47:58PM +0100, Chris Wilson wrote:
+ /* We also want to clear any cached iomaps as they wrap vmap */
+ list_for_
On 15/04/16 10:50, Tomeu Vizoso wrote:
When moving the call to gem_set_tiling into the subtests, the one needed
by addfb25-framebuffer-vs-set-tiling was left out.
Signed-off-by: Tomeu Vizoso
---
tests/kms_addfb_basic.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tests/kms_addfb_basi
From: Tvrtko Ursulin
Reflect the status of obj->mapping as added with the
i915_gem_object_pin_map API.
'M' was chosen to designate the pin mapped status.
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 34 +++
From: Tvrtko Ursulin
Show a total and purgeable number of pin mapped objects
and their total and purgeable size.
Example output (new stat prefixed with a star):
# cat i915_gem_objects
19920 objects, 289243136 bytes
19920 [18466] objects, 288714752 [267911168] bytes in gtt
0 [0] active
From: Tvrtko Ursulin
Just two WARN_ONs followed by pointer dereference I spotted by accident.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_lrc.c| 2 --
drivers/gpu/drm/i915/intel_ringbuffer.c | 7 +--
2 files changed, 1 insertion(+), 8 deletions(-)
diff --git a/dri
On Fri, Apr 15, 2016 at 11:19:30AM +0100, Tvrtko Ursulin wrote:
> On 15/04/16 11:00, Chris Wilson wrote:
> >On Fri, Apr 15, 2016 at 10:40:42AM +0100, Tvrtko Ursulin wrote:
> >>
> >>On 13/04/16 16:12, Chris Wilson wrote:
> >>>On Wed, Apr 13, 2016 at 03:47:58PM +0100, Chris Wilson wrote:
> + /* W
On Fri, Apr 15, 2016 at 11:37:18AM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Just two WARN_ONs followed by pointer dereference I spotted by accident.
>
> Signed-off-by: Tvrtko Ursulin
I too keep removing these.
Reviewed-by: Chris Wilson
A couple more patch series and we'll be o
On 15/04/16 11:38, Chris Wilson wrote:
On Fri, Apr 15, 2016 at 11:19:30AM +0100, Tvrtko Ursulin wrote:
On 15/04/16 11:00, Chris Wilson wrote:
On Fri, Apr 15, 2016 at 10:40:42AM +0100, Tvrtko Ursulin wrote:
On 13/04/16 16:12, Chris Wilson wrote:
On Wed, Apr 13, 2016 at 03:47:58PM +0100, Chri
Daniel, are we able to upstream the pooled EU support now. Looks like an open
Source user will be with us soon. This is basically the same patch that Arun
submitted
last year, just rebased. Further comments welcome of course
Tim
Tim Gore
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipe
On Wednesday 13 April 2016 08:16 PM, Daniel Vetter wrote:
On Wed, Apr 13, 2016 at 06:34:25PM +0530, Ramalingam C wrote:
On Wednesday 13 April 2016 05:27 PM, Daniel Vetter wrote:
On Wed, Apr 13, 2016 at 1:48 PM, Daniel Vetter wrote:
On Wed, Apr 13, 2016 at 1:06 PM, Jani Nikula wrote:
Then f
When mixing lots of vmallocs and set_memory_*() (which calls
vm_unmap_aliases()) I encountered situations where the performance
degraded severely due to the walking of the entire vmap_area list each
invocation. One simple improvement is to add the lazily freed vmap_area
to a separate lockless free
On 15/04/2016 11:04, Tvrtko Ursulin wrote:
On 14/04/16 18:19, Dave Gordon wrote:
With the new i915_gem_obj_pin_map() interface, it makes sense to keep
GuC objects (which are always pinned in memory and in the GGTT anyway)
mapped into kernel address space, rather than mapping and unmapping them
On Thu, Apr 14, 2016 at 04:44:48PM +0200, Roman Peniaev wrote:
> On Thu, Apr 14, 2016 at 3:49 PM, Chris Wilson
> wrote:
> > On Thu, Apr 14, 2016 at 03:13:26PM +0200, Roman Peniaev wrote:
> >> Hi, Chris.
> >>
> >> Is it made on purpose not to drop VM_LAZY_FREE flag in
> >> __purge_vmap_area_lazy()
On Fri, Apr 15, 2016 at 10:16:25AM +0100, Peter Antoine wrote:
> Thanks for tidying up and pushing.
Fwiw, I extended the test to demonstrate that !rcs engines are also
suspectible to the same pollution where one process can affect the
register settings of an another.
-Chris
--
Chris Wilson, Inte
Two different sets of flag bits are stored in the 'flags' member of a
'struct drm_i915_gem_exec_object2', and they're defined in two different
source files, increasing the risk of an accidental clash.
Some flags in this field are supplied by the user; these are defined in
i915_drm.h, and they star
It may not be obvious, but the current execbuffer2 ioctl interface
requires that the buffer object containing the batch-to-be-executed
be the LAST entry in the exec2_list[] array (I expected it to be
the first!).
To clarify this, we can replace the rather obscure construct
"list_entry(eb->
Precursor for fix to secure batch execution. We will need to be able to
retrieve the batch VMA (as well as the batch itself) from the eb list,
so this patch extracts that part of eb_get_batch() into a separate
function, and moves both parts to a more logical place in the file, near
where the eb lis
There is a problem with the relocation of batches submitted with the
I915_EXEC_SECURE flag: although the batch itself will be mapped into the
GGTT, any relocations referring to it will use its address in the PPGTT,
which almost certainly won't be the same.
Hence a batch containing an MI_BATCH_BUFF
On 15/04/16 12:12, Dave Gordon wrote:
On 15/04/2016 11:04, Tvrtko Ursulin wrote:
On 14/04/16 18:19, Dave Gordon wrote:
With the new i915_gem_obj_pin_map() interface, it makes sense to keep
GuC objects (which are always pinned in memory and in the GGTT anyway)
mapped into kernel address space,
On Fri, Apr 15, 2016 at 12:32:57PM +0100, Dave Gordon wrote:
> There is a problem with the relocation of batches submitted with the
> I915_EXEC_SECURE flag: although the batch itself will be mapped into the
> GGTT, any relocations referring to it will use its address in the PPGTT,
> which almost ce
On Fri, Apr 15, 2016 at 1:07 PM, Chris Wilson wrote:
> When mixing lots of vmallocs and set_memory_*() (which calls
> vm_unmap_aliases()) I encountered situations where the performance
> degraded severely due to the walking of the entire vmap_area list each
> invocation. One simple improvement is
From: Tvrtko Ursulin
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_params.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 1779f02e6df8..128506347134 100644
--- a/drivers/gpu/drm/i9
From: Tvrtko Ursulin
In GuC mode submitting requests is only putting them into the
GuC queue with the actual submission to hardware following at
some future point. This makes the per engine last context
tracking insufficient for closing the premature context
unpin race.
Instead we need to make r
From: Chris Wilson
Refactor pinning and unpinning of contexts, such that the default
context for an engine is pinned during initialisation and unpinned
during teardown (pinning of the context handles the reference counting).
Thus we can eliminate the special case handling of the default context
t
From: Tvrtko Ursulin
Just exercising the fix for GuC premature LRC unpin on the CI.
Chris Wilson (1):
drm/i915: Refactor execlists default context pinning
Tvrtko Ursulin (2):
drm/i915/guc: Keep the previous context pinned until the next one has
been completed
DO NOT MERGE: drm/i915: E
When userspace closes a handle, we remove it from the file->object_idr
and then tell the driver to drop its references to that file/handle.
However, as the file/handle is already available again for reuse, it may
be reallocated back to userspace and active on a new object before the
driver has had
The variable used as loop counter in the igt_fixture macro had
unspecified value from the setjmp(3) man page quoted below. Because of
that, in certain circumstances and with -O2 and -Os, the initialization
of that variable would be eliminated and the compiler would complain of
uninitialized usage.
On ti, 2016-04-05 at 12:19 +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/bxt: Fix/enable display power well support/runtime
> PM (rev5)
> URL : https://patchwork.freedesktop.org/series/5177/
> State : success
Thanks for the reviews, I pushed the patchset to -dinq.
As agre
On Fri, Apr 15, 2016 at 12:54:34PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> In GuC mode submitting requests is only putting them into the
> GuC queue with the actual submission to hardware following at
> some future point. This makes the per engine last context
> tracking insuffici
== Series Details ==
Series: series starting with [resend-for-CI,1/2] drm/i915: Show pin mapped
status in describe_obj
URL : https://patchwork.freedesktop.org/series/5771/
State : failure
== Summary ==
Series 5771v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/5
On Fri, Apr 15, 2016 at 12:54:33PM +0100, Tvrtko Ursulin wrote:
> From: Chris Wilson
>
> Refactor pinning and unpinning of contexts, such that the default
> context for an engine is pinned during initialisation and unpinned
> during teardown (pinning of the context handles the reference counting)
On Wed, 2016-04-13 at 11:18 +0200, Maarten Lankhorst wrote:
> Do it in 1 step instead, use atomic_read since INTEL_FLIP_COMPLETE
> is no longer useful.
What's the deal with "use atomic_read"? I couldn't find where that is different
from the old code.
>
> Signed-off-by: Maarten Lankhorst
> ---
On 15/04/2016 12:43, Chris Wilson wrote:
On Fri, Apr 15, 2016 at 12:32:57PM +0100, Dave Gordon wrote:
There is a problem with the relocation of batches submitted with the
I915_EXEC_SECURE flag: although the batch itself will be mapped into the
GGTT, any relocations referring to it will use its a
On Wed, 2016-04-13 at 11:18 +0200, Maarten Lankhorst wrote:
> Rename intel_unpin_work to intel_flip_work and use it for mmio flips
> and unpinning.
I think the rename should be a separate patch.
Ander
> Use flip_queued_req to hold the wait request in the
> mmio case and allow the vblank interru
On Fri, Apr 15, 2016 at 06:26:18AM -, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [v4,1/3] drm/edid: Add
> drm_edid_get_monitor_name()
> URL : https://patchwork.freedesktop.org/series/5731/
> State : failure
>
> == Summary ==
>
> Series 5731v1 Series without c
On Fri, Apr 15, 2016 at 12:55:08PM +0100, Chris Wilson wrote:
> When userspace closes a handle, we remove it from the file->object_idr
> and then tell the driver to drop its references to that file/handle.
> However, as the file/handle is already available again for reuse, it may
> be reallocated b
Due to "some hardware limitation" the DPI enable bit in port C control
register does not get set on VLV. As a workaround we check the status in
pipe B conf register instead. The workaround was added in
commit c0beefd29fcb1ca998f0f9ba41be8539f8eeba9b
Author: Gaurav K Singh
Date: Tue Dec 9 10:59:
On Tue, 12 Apr 2016, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Here is the remainder of my DSI/DPLL series [1]. Everything else got merged
> already. The first patch in the series is the only one to lack an r-b.
>
> Tested on BYT FFRD8 only, BXT stuff is not tested.
I didn't
On Fri, Apr 15, 2016 at 03:47:31PM +0300, Jani Nikula wrote:
> Due to "some hardware limitation" the DPI enable bit in port C control
> register does not get set on VLV. As a workaround we check the status in
> pipe B conf register instead. The workaround was added in
>
> commit c0beefd29fcb1ca998
So those subtests that require tiling don't cause unrelated subtests to
be skipped.
Signed-off-by: Tomeu Vizoso
---
tests/kms_addfb_basic.c | 148
1 file changed, 73 insertions(+), 75 deletions(-)
diff --git a/tests/kms_addfb_basic.c b/tests/kms_
On Tue, 12 Apr 2016, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Set up DPLL and DPLL_MD even when driving DSI output on VLV/CHV. While
> the DPLL isn't used to provide the clock we still need the refclock, and
> it appears that the pixel repeat factor also has an effect on DSI
On 15/04/16 13:12, Chris Wilson wrote:
On Fri, Apr 15, 2016 at 12:54:34PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
In GuC mode submitting requests is only putting them into the
GuC queue with the actual submission to hardware following at
some future point. This makes the per engine
On 15/04/16 13:16, Chris Wilson wrote:
On Fri, Apr 15, 2016 at 12:54:33PM +0100, Tvrtko Ursulin wrote:
From: Chris Wilson
Refactor pinning and unpinning of contexts, such that the default
context for an engine is pinned during initialisation and unpinned
during teardown (pinning of the contex
On Fri, Apr 15, 2016 at 04:09:31PM +0300, Jani Nikula wrote:
> On Tue, 12 Apr 2016, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Set up DPLL and DPLL_MD even when driving DSI output on VLV/CHV. While
> > the DPLL isn't used to provide the clock we still need the refclock, a
On 14 April 2016 at 21:17, Boris Brezillon
wrote:
> Use pwm_get/set_xxx() helpers instead of directly accessing the pwm->xxx
> field. Doing that will ease adaptation of the PWM framework to support
> atomic update.
>
> Signed-off-by: Boris Brezillon
> ---
> Patch generated with the following cocc
On 04/14/2016 09:17 PM, Boris Brezillon wrote:
> Call pwm_apply_args() just after requesting the PWM device so that the
> polarity and period are initialized according to the information provided
> in pwm_args.
>
> This is an intermediate state, and pwm_apply_args() should be dropped as
> soon as
On to, 2016-04-14 at 15:37 -0700, Dongwon Kim wrote:
> This patch is to correct one thing in this commit:
>
> commit 25a56705332add0363e47b3a0eca001d6fbd5bec
> Author: Dongwon Kim
> Date: Wed Mar 16 18:06:13 2016 -0700
>
> drm/i915/bxt: Reversed polarity of PORT_PLL_REF_SEL bit
>
> Fo
Looks like we might not need to worry about this patch anymore actually, looks
like this problem got fixed by accident by one of the other vlv fixes you
pushed. Now it's not always modesetting on hotplug when it was before though :(,
so I'll get to work on bisecting that.
On Thu, 2016-04-14 at 20:
== Series Details ==
Series: mm/vmalloc: Keep a separate lazy-free list (rev2)
URL : https://patchwork.freedesktop.org/series/5574/
State : failure
== Summary ==
Series 5574v2 mm/vmalloc: Keep a separate lazy-free list
http://patchwork.freedesktop.org/api/1.0/series/5574/revisions/2/mbox/
Tes
== Series Details ==
Series: series starting with [resend-for-CI,1/2] drm/i915: Show pin mapped
status in describe_obj
URL : https://patchwork.freedesktop.org/series/5771/
State : success
== Summary ==
Series 5771v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/5
On 15/04/16 14:50, Patchwork wrote:
== Series Details ==
Series: series starting with [resend-for-CI,1/2] drm/i915: Show pin mapped
status in describe_obj
URL : https://patchwork.freedesktop.org/series/5771/
State : success
== Summary ==
Series 5771v1 Series without cover letter
http://pat
This is part of a patch series to migrate all of the workarounds for
commonly seen behavior from bad sinks in intel_dp_dpcd_read_wake() to drm's
DP helper.
Some sinks will just return garbage for the first aux tranaction they
receive when coming out of sleep mode, so we need to perform an addition
On Fri, Apr 15, 2016 at 10:25:35AM -0400, Lyude wrote:
> This is part of a patch series to migrate all of the workarounds for
> commonly seen behavior from bad sinks in intel_dp_dpcd_read_wake() to drm's
> DP helper.
>
> Some sinks will just return garbage for the first aux tranaction they
> recei
== Series Details ==
Series: series starting with [1/4] drm/i915: compile-time consistency check on
__EXEC_OBJECT flags
URL : https://patchwork.freedesktop.org/series/5775/
State : warning
== Summary ==
Series 5775v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/
== Series Details ==
Series: GuC premature LRC unpin
URL : https://patchwork.freedesktop.org/series/5776/
State : warning
== Summary ==
Series 5776v1 GuC premature LRC unpin
http://patchwork.freedesktop.org/api/1.0/series/5776/revisions/1/mbox/
Test gem_busy:
Subgroup basic-blt:
On Fri, Apr 15, 2016 at 09:47:51AM -0400, Lyude Paul wrote:
> Looks like we might not need to worry about this patch anymore actually, looks
> like this problem got fixed by accident by one of the other vlv fixes you
> pushed.
Not sure what exactly changed for you, but we definitely need to
reinit
On Mon, Apr 04, 2016 at 02:18:10PM +0100, Chris Wilson wrote:
> From: Akash Goel
>
> This provides support for the drivers or shmem file owners to register
> a set of callbacks, which can be invoked from the address space
> operations methods implemented by shmem. This allow the file owners to
>
== Series Details ==
Series: drm/i915/dsi: fix CHV dsi encoder hardware state readout on port C
URL : https://patchwork.freedesktop.org/series/5781/
State : failure
== Summary ==
Series 5781v1 drm/i915/dsi: fix CHV dsi encoder hardware state readout on port C
http://patchwork.freedesktop.org/a
Huh, neither am I now. I seem to be able to reproduce the problem just fine
again. Anyway I'll send the new versions of the patches in a little bit
On Fri, 2016-04-15 at 18:49 +0300, Ville Syrjälä wrote:
> On Fri, Apr 15, 2016 at 09:47:51AM -0400, Lyude Paul wrote:
> >
> > Looks like we might not
Hello
It seems this patch works on 4.4 kernel.
https://bugzilla.kernel.org/attachment.cgi?id=195071
Maybe we can have it directly in future releases?
:)
Regards,
Le 23/03/2016 12:36, Jani Nikula a écrit :
On Tue, 22 Mar 2016, Nicolas Repentin wrote:
I'm searching for a fix for thread
ht
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c| 7 ++---
drivers/gpu/drm/i915/i915_drv.h| 18 ++-
drivers/gpu/drm/i915/i915_gem.c| 48 +++---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 21 +
driver
This is primarily intended to simplify later patches that add various
backpointers to the structs, but in the meantime we can enjoy various
little syntactic conveniences.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 12 +-
drivers/gpu/drm/i915/i915_drv.h
Final canvas for opinions for using a magic macro to reduce typing in
the common operation of getting our drm_i915_private from the object.
21 files changed, 333 insertions(+), 392 deletions(-)
Not to mention the ease it makes for later patches to reduce the pointer
dance.
-Chris
__
Rather than require the user to grab a drm_i915_private, allow them to
pass anything that we know how to derive such a pointer user to_i915()
Note this fixes a macro bug in for_each_engine_masked() which was not
using its dev_priv__ parameter.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
Since drm_i915_gem_request already contains a backpointer to
drm_i915_private, this is a fairly trivial operation. However, using a
consistent interface does lean convenience to when we need to query
device properties, for example.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h
The convenience of saving a few characters by using a consistent
interface to obtain our drm_i915_private struct from intel_guc.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h| 5 -
drivers/gpu/drm/i915/i915_guc_submission.c | 17 +++--
2 files chang
To open up the future of using a generic to_i915() convenience macro,
rename the existing __I915__ superconvenience macro.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/
On Thu, 2016-04-14 at 11:48 +0200, Daniel Vetter wrote:
> On Wed, Apr 13, 2016 at 10:06:57PM +, Vivi, Rodrigo wrote:
> > On Wed, 2016-04-13 at 22:46 +0200, Daniel Vetter wrote:
> > > On Wed, Apr 13, 2016 at 10:38 PM, Vivi, Rodrigo <
> > > rodrigo.v...@intel.com> wrote:
> > > > On Wed, 2016-04-1
The workaround added in c6782b76d31a ("drm/i915/gen9: Reset secondary power
well requests left on by DMC/KVMR") needs to be applied on Kabylake too as
shown by the corresponding timeout errors about power well 1 and MISC IO
power well disabling in the latest CI run.
CC: Patrik Jakobsson
Signed-of
This lets call intel_crt_reset() in contexts where IRQs are disabled and
as such, can't hold the locks required to work with the connectors.
CC: sta...@vger.kernel.org
Signed-off-by: Lyude
---
drivers/gpu/drm/i915/intel_crt.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff
While VGA hotplugging worked(ish) before, it looks like that was mainly
because we'd unintentionally enable it in
valleyview_crt_detect_hotplug() when we did a force trigger. This
doesn't work reliably enough because whenever the display powerwell on
vlv gets disabled, the values set in VLV_ADPA ge
Hi all,
We are pleased to announce another update of Intel GVT-g for KVM.
Intel GVT-g for KVM (a.k.a. KVMGT) is a full GPU virtualization solution with
mediated pass-through, starting from 4th generation Intel Core(TM) processors
with Intel Graphics processors. A virtual GPU instance is mainta
94 matches
Mail list logo
