Quoting Daniele Ceraolo Spurio (2019-01-10 01:32:31)
> By using the wa lists inside the live driver structures, we won't
> catch issues where those are incorrectly setup or corrupted.
> To cover this gap, update the workaround framework to allow saving the
> wa lists to independent structures and u
Quoting Daniele Ceraolo Spurio (2019-01-10 01:32:32)
> commit 4a15c75c4246 ("drm/i915: Introduce per-engine workarounds")
> refactored the workaround code to have functions per-engine, but didn't
> call any of them from logical_xcs_ring_init. Since we do have a non-RCS
> workaround for KBL (WaKBLVE
Hi Dave/Daniel,
drm-misc-fixes-2019-01-10:
Pull request for drm-misc-fixes for v5.0-rc2:
- Fixes for the tc358767 bridge to work correctly with
tc358867 using a DP connector.
- Make resume work on amdgpu when a DP-MST display is unplugged.
The following changes since commit bfeffd155283772bbe78c
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/selftests: recreate WA lists
inside the selftest
URL : https://patchwork.freedesktop.org/series/54967/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5386_full -> Patchwork_11271_full
=
== Series Details ==
Series: drm/i915: Reduce i915_request_alloc retirement to local context (rev3)
URL : https://patchwork.freedesktop.org/series/54820/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5386_full -> Patchwork_11270_full
===
== Series Details ==
Series: drm/i915: drop DPF code for gen8+
URL : https://patchwork.freedesktop.org/series/54963/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5386_full -> Patchwork_11269_full
Summary
---
**SUCCE
== Series Details ==
Series: drm/i915: init per-engine WAs for all engines
URL : https://patchwork.freedesktop.org/series/54962/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5386_full -> Patchwork_11268_full
Summary
--
On 2019.01.08 10:25:45 +0200, Jani Nikula wrote:
> drmP.h is deprecated and no longer needed.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/gvt/dmabuf.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/dmabuf.c
> b/drivers/gpu/drm/i915/gvt/dmabuf.c
Looks good to me.
Reviewed-by: Yan Zhao
> -Original Message-
> From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
> Behalf Of Jani Nikula
> Sent: Tuesday, January 8, 2019 10:12 PM
> To: intel-gvt-...@lists.freedesktop.org
> Cc: Nikula, Jani ; intel-gfx@lists.freed
Looks good to me.
Reviewed-by: Yan Zhao
> -Original Message-
> From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
> Behalf Of Jani Nikula
> Sent: Tuesday, January 8, 2019 10:12 PM
> To: intel-gvt-...@lists.freedesktop.org
> Cc: Nikula, Jani ; intel-gfx@lists.freed
On Thu, 2019-01-03 at 06:21 -0800, José Roberto de Souza wrote:
> This register contains how many blocks was sent in the past selective
> updates.
> Those registers are not kept set all the times but pulling it after
I suppose you mean 'polling'.
> flip
> can show that the expected values are set
On Thu, 2019-01-03 at 06:21 -0800, José Roberto de Souza wrote:
> The value of this registers will be used to test if PSR2 is doing
> selective update and if the number of blocks match with the expected.
>
> v2:
> - Using new macros
> - Changed the string output
>
> Cc: Rodrigo Vivi
> Cc: Dhinak
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/selftests: recreate WA lists
inside the selftest
URL : https://patchwork.freedesktop.org/series/54967/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5386 -> Patchwork_11271
===
== Series Details ==
Series: drm/i915: Fix the static code analysis warning in debugfs
URL : https://patchwork.freedesktop.org/series/54961/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5386_full -> Patchwork_11267_full
Su
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/selftests: recreate WA lists
inside the selftest
URL : https://patchwork.freedesktop.org/series/54967/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
389635e85573 drm/i915/selftests: recreate WA lists inside th
commit 4a15c75c4246 ("drm/i915: Introduce per-engine workarounds")
refactored the workaround code to have functions per-engine, but didn't
call any of them from logical_xcs_ring_init. Since we do have a non-RCS
workaround for KBL (WaKBLVECSSemaphoreWaitPoll) we do need to call
intel_engine_init_wor
By using the wa lists inside the live driver structures, we won't
catch issues where those are incorrectly setup or corrupted.
To cover this gap, update the workaround framework to allow saving the
wa lists to independent structures and use them in the selftests.
Suggested-by: Chris Wilson
Cc: Ch
On Thu, 2019-01-03 at 06:21 -0800, José Roberto de Souza wrote:
> PSR2 only trigger interruptions for AUX error, so let's not print
> useless information in debugfs.
> Also adding a comment to intel_psr_irq_handler() about that.
>
Is it worth keeping this stuff for PSR1 if PSR2 is not supported, d
On 1/9/2019 16:24, John Harrison wrote:
On 1/7/2019 03:54, Chris Wilson wrote:
Frequently, we use intel_runtime_pm_get/_put around a small block.
Formalise that usage by providing a macro to define such a block with an
automatic closure to scope the intel_runtime_pm wakeref to that block,
i.e. m
On 1/7/2019 03:54, Chris Wilson wrote:
The majority of runtime-pm operations are bounded and scoped within a
function; these are easy to verify that the wakeref are handled
correctly. We can employ the compiler to help us, and reduce the number
of wakerefs tracked when debugging, by passing aroun
On 1/7/2019 03:54, Chris Wilson wrote:
Frequently, we use intel_runtime_pm_get/_put around a small block.
Formalise that usage by providing a macro to define such a block with an
automatic closure to scope the intel_runtime_pm wakeref to that block,
i.e. macro abuse smelling of python.
Signed-of
== Series Details ==
Series: drm/i915: Reduce i915_request_alloc retirement to local context (rev3)
URL : https://patchwork.freedesktop.org/series/54820/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5386 -> Patchwork_11270
== Series Details ==
Series: drm/i915: drop DPF code for gen8+
URL : https://patchwork.freedesktop.org/series/54963/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5386 -> Patchwork_11269
Summary
---
**SUCCESS**
No
On 1/9/2019 03:16, Mika Kuoppala wrote:
Chris Wilson writes:
diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c
b/drivers/gpu/drm/i915/i915_gem_shrinker.c
index 16693dd4d019..bc230e43b98f 100644
--- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
@
== Series Details ==
Series: drm/i915: Reduce i915_request_alloc retirement to local context (rev3)
URL : https://patchwork.freedesktop.org/series/54820/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
4f7a98cdc73c drm/i915: Reduce i915_request_alloc retirement to local context
-
On 1/9/2019 03:51, Chris Wilson wrote:
Quoting Mika Kuoppala (2019-01-09 09:23:53)
I should have been more specific. My concern was on documenting
the changing return values.
The interface isn't documented, there's nothing in the header about the
functions? Where else would it be?
I think Mik
== Series Details ==
Series: drm/i915: init per-engine WAs for all engines
URL : https://patchwork.freedesktop.org/series/54962/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5386 -> Patchwork_11268
Summary
---
**WAR
== Series Details ==
Series: drm/i915: Fix the static code analysis warning in debugfs
URL : https://patchwork.freedesktop.org/series/54961/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5386 -> Patchwork_11267
Summary
On Thu, 2019-01-03 at 06:21 -0800, José Roberto de Souza wrote:
> The old debugfs fields was not following a naming partern and it was
> a bit confusing.
>
> So it went from:
> ~$ sudo more /sys/kernel/debug/dri/0/i915_edp_psr_status
> Sink_Support: yes
> PSR mode: PSR1
> Enabled: yes
> Busy front
On Thu, 2019-01-03 at 06:21 -0800, José Roberto de Souza wrote:
> For now PSR2 is still disabled by default for all platforms but is
> our intention to let debugfs to enable it for debug and tests
> proporses, so intel_psr2_enabled() that is also used by debugfs to
> decide if PSR2 is going to be e
In the continual quest to reduce the amount of global work required when
submitting requests, replace i915_retire_requests() after allocation
failure to retiring just our ring.
v2: Don't forget the list iteration included an early break, so we would
never throttle on the last request in the ring/t
Quoting Chris Wilson (2019-01-09 21:48:29)
> Quoting Daniele Ceraolo Spurio (2019-01-09 21:30:38)
> > commit 4a15c75c4246 ("drm/i915: Introduce per-engine workarounds")
> > refactored the workaround code to have functions per-engine, but didn't
> > call any of them from logical_xcs_ring_init. Since
Quoting Daniele Ceraolo Spurio (2019-01-09 21:30:38)
> commit 4a15c75c4246 ("drm/i915: Introduce per-engine workarounds")
> refactored the workaround code to have functions per-engine, but didn't
> call any of them from logical_xcs_ring_init. Since we do have a non-RCS
> workaround for KBL (WaKBLVE
Quoting Daniele Ceraolo Spurio (2019-01-09 21:31:47)
> The only gen8+ platform that has the feature is BDW, but we don't define
> the feature flag on any BDW platform and we only have partial support in
> the gen8 path (irq enabling code, but no handler).
> The only thing we could do in the irq han
The only gen8+ platform that has the feature is BDW, but we don't define
the feature flag on any BDW platform and we only have partial support in
the gen8 path (irq enabling code, but no handler).
The only thing we could do in the irq handler is report the error
to userspace, but no one asked/cared
commit 4a15c75c4246 ("drm/i915: Introduce per-engine workarounds")
refactored the workaround code to have functions per-engine, but didn't
call any of them from logical_xcs_ring_init. Since we do have a non-RCS
workaround for KBL (WaKBLVECSSemaphoreWaitPoll) we do need to call
intel_engine_init_wor
On Wed, Jan 09, 2019 at 01:14:14PM -0800, Radhakrishna Sripada wrote:
> intel_dp->dsc_dpcd is defined as an array making the if check redundant.
>
Yes I agree, I guess when I added that if check it was anot an array to begin
with and then forgot to take it off.
Looks good to me.
Reviewed-by: Man
intel_dp->dsc_dpcd is defined as an array making the if check redundant.
Cc: Rodrigo Vivi
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/i915_debugfs.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i
Quoting Tvrtko Ursulin (2019-01-09 14:12:46)
> From: Tvrtko Ursulin
>
> In two codepaths internal to the shrinker we know we will end up taking
> the resursive mutex path.
>
> It instead feels more elegant to avoid this altogether and not call
> mutex_trylock_recursive in those cases.
>
> We ac
Looks good to me.
> -Original Message-
> From: Souza, Jose
> Sent: Friday, January 4, 2019 9:37 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Oscar Mateo ; Sripada, Radhakrishna
> ; Souza, Jose
> Subject: [PATCH] drm/i915/icl: Apply
> WaEnablePreemptionGranularityControlByUMD
>
> Accord
== Series Details ==
Series: drm/i915/psr: simplify enable_psr handling
URL : https://patchwork.freedesktop.org/series/54959/
State : failure
== Summary ==
Applying: drm/i915/psr: simplify enable_psr handling
Using index info to reconstruct a base tree...
M drivers/gpu/drm/i915/i915_drv.
On Tue, Dec 25, 2018 at 02:24:36PM +, ? ? wrote:
> Package: Linux-image-amd64
> Version: 4.18+100~bpo9+1
>
> Linux-4.18.20 fail to boot on old intel gfx card.
> I also tried a fresh installed Debian testing with same kernel version,
> still can't boot, even to command line interface.
>
> afte
I just got a used Thinkpad X201 (Core i5 M 520, Intel QM57
chipset) and hit some kernel panics while trying to view
image/animation-intensive stuff in Firefox (X11) unless I use
"iommu_intel=igfx_off".
With Debian stable backport kernels, "linux-image-4.17.0-0.bpo.3-amd64"
(4.17.17-1~bpo9+1) has n
I should really get to bed ... of course, I meant
516a49cc19467e298d08a404f73a6e311f4548d1 ;-)
On Sat, 5 Jan 2019 at 01:16, Daniel Kamil Kozar wrote:
>
> Small omission on my part : I meant 4.19.12, not 4.19.2 as the last
> working version.
> Also, I can confirm that reverting
> 13947d150bae871bd
The following commit:
commit 2bdd045e3a30 ("drm/i915/psr: Check if VBT says PSR can be enabled.")
added some code with no usable functionality. Regardless of how the psr
default is set up in the BDB_DRIVER_FEATURES section, if the enable_psr
module parameter isn't specified it defaults to 0.
Re
Jani et al,
Do I need to do more? For instance adding people to the cc-list or is
the bug visible to everybody?
Regards,
Jan
On 02-01-19 13:34, Jan Vlietland wrote:
Thank you. I just did.
https://bugs.freedesktop.org/show_bug.cgi?id=109209
Met vriendelijke groet,
*dr. Jan Vlietland*, na
Hi, Greg
I found on Debian testing with kernel 4.18.20 fail boot, kernel panic
on i915. and reported it to Debian bug 917280 [0], with panic log[1].
after revert:
commit 06e562e7f515292ea7721475950f23554214adde
Author: Chris Wilson
Date: Mon Nov 5 09:43:05 2018 +
drm/i915/ringbuffer:
Hello all,
First of all happy new year. Based on advice of Greg K-H herewith a mail
about my continuous (frustrating) issue with my laptop.
I installed various Kali linux versions up to Linux 4.20.0-rc7
(downloaded, compiled and installed) on a Samsung NP900X5N laptop and
have an issue with
Package: Linux-image-amd64
Version: 4.18+100~bpo9+1
Linux-4.18.20 fail to boot on old intel gfx card.
I also tried a fresh installed Debian testing with same kernel version,
still can't boot, even to command line interface.
after blacklisting i915, Debian testing can boot to command line
interfac
I submitted the bug report at
https://bugs.freedesktop.org/show_bug.cgi?id=109245 . The dmesg log is
attached to the bug report.
Daniel
On Mon, 7 Jan 2019 at 14:34, Ville Syrjälä
wrote:
>
> On Sat, Jan 05, 2019 at 12:47:12AM +0100, Daniel Kamil Kozar wrote:
> > Hello.
> > After upgrading the ker
Thank you. I just did.
https://bugs.freedesktop.org/show_bug.cgi?id=109209
Met vriendelijke groet,
*dr. Jan Vlietland*, namens
spin-off
Nederlands Instituut voor de Software Industrie
_j.vlietland@nisi.nl_| 06 – 20 411 834 | 030 – 268 53 98
Princetonplein 5 | 3584 CC Utrecht | www.nisi.nl
Joonas Lahtinen wrote:
> Quoting Eric Wong (2018-12-27 13:49:48)
> > I just got a used Thinkpad X201 (Core i5 M 520, Intel QM57
> > chipset) and hit some kernel panics while trying to view
> > image/animation-intensive stuff in Firefox (X11) unless I use
> > "iommu_intel=igfx_off".
> >
> > With D
On Fri, Dec 21, 2018 at 11:23:07AM -0800, Dhinakaran Pandiyan wrote:
> On Fri, 2018-12-21 at 10:23 -0700, Ross Zwisler wrote:
> > The following commit:
> >
> > commit 2bdd045e3a30 ("drm/i915/psr: Check if VBT says PSR can be
> > enabled.")
> >
> > added some code with no usable functionality. Re
Small omission on my part : I meant 4.19.12, not 4.19.2 as the last
working version.
Also, I can confirm that reverting
13947d150bae871bd880565ada318b0bcd0e690e from the current HEAD of
linux-stable fixes the issue.
On Sat, 5 Jan 2019 at 00:47, Daniel Kamil Kozar wrote:
>
> Hello.
> After upgradi
Hello.
After upgrading the kernel to 4.20, I noticed that the boot time
increased from about 5 seconds to 25 seconds. My machine is an Asus
K53SV with an Intel i7-2630QM, i.e. Sandy Bridge. I have an external
display connected to it via HDMI. If the display is unplugged when
booting the machine, th
== Series Details ==
Series: series starting with [1/2] drm/i915: Use mutex_lock_killable() from
inside the shrinker
URL : https://patchwork.freedesktop.org/series/54952/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5383_full -> Patchwork_11265_full
=
== Series Details ==
Series: series starting with [1/2] drm/i915: Reduce recursive mutex locking
from the shrinker
URL : https://patchwork.freedesktop.org/series/54948/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5383_full -> Patchwork_11264_full
===
== Series Details ==
Series: series starting with [1/2] drm/i915: Use mutex_lock_killable() from
inside the shrinker
URL : https://patchwork.freedesktop.org/series/54952/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5383 -> Patchwork_11265
===
On Mon, Jan 07, 2019 at 11:19:31AM -0800, Matt Roper wrote:
> On Mon, Jan 07, 2019 at 01:23:50PM +0100, Michał Winiarski wrote:
> > On Mon, Jan 07, 2019 at 01:01:16PM +0200, Joonas Lahtinen wrote:
> > > Quoting José Roberto de Souza (2019-01-04 19:37:00)
> > > > According to Workaround database ICL
== Series Details ==
Series: drm/i915: Reduce i915_request_alloc retirement to local context (rev2)
URL : https://patchwork.freedesktop.org/series/54820/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5383_full -> Patchwork_11263_full
===
== Series Details ==
Series: series starting with [1/2] drm/i915: Use mutex_lock_killable() from
inside the shrinker
URL : https://patchwork.freedesktop.org/series/54952/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Use mutex_lock_killable
== Series Details ==
Series: series starting with [1/2] drm/i915: Use mutex_lock_killable() from
inside the shrinker
URL : https://patchwork.freedesktop.org/series/54952/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
5591d0fa3da6 drm/i915: Use mutex_lock_killable() from inside
The wait-for-idle used from within the shrinker_lock_uninterruptible
depends on the struct_mutex locking state being known and declared to
i915_request_wait(). As it is conceivable that we reach the vmap
notifier from underneath struct_mutex (and so keep on relying on the
mutex_trylock_recursive),
If the current process is being killed (it was interrupted with SIGKILL
or equivalent), it will not make any progress in page allocation and we
can abort performing the shrinking on its behalf. So we can use
mutex_lock_killable() instead (although this path should only be
reachable from kswapd curr
== Series Details ==
Series: drm/i915: Try to sanitize bogus DPLL state left over by broken SNB
BIOSen
URL : https://patchwork.freedesktop.org/series/54942/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5383_full -> Patchwork_11262_full
===
Quoting Tvrtko Ursulin (2019-01-09 15:07:34)
>
> On 09/01/2019 14:23, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-01-09 14:12:47)
> >> From: Tvrtko Ursulin
> >>
> >> The code tries to grab struct mutex for 5ms every time the unlocked GPU
> >> idle wait succeeds. But the GPU idle wait its
On 09/01/2019 14:23, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-09 14:12:47)
From: Tvrtko Ursulin
The code tries to grab struct mutex for 5ms every time the unlocked GPU
idle wait succeeds. But the GPU idle wait itself is practically unbound
which means the 5ms timeout might not be h
== Series Details ==
Series: series starting with [1/2] drm/i915: Reduce recursive mutex locking
from the shrinker
URL : https://patchwork.freedesktop.org/series/54948/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5383 -> Patchwork_11264
=
== Series Details ==
Series: drm/i915: Reduce i915_request_alloc retirement to local context (rev2)
URL : https://patchwork.freedesktop.org/series/54820/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5383 -> Patchwork_11263
Chris Wilson writes:
> Frequently, we use intel_runtime_pm_get/_put around a small block.
> Formalise that usage by providing a macro to define such a block with an
> automatic closure to scope the intel_runtime_pm wakeref to that block,
> i.e. macro abuse smelling of python.
>
> Signed-off-by: C
Quoting Tvrtko Ursulin (2019-01-09 14:12:47)
> From: Tvrtko Ursulin
>
> The code tries to grab struct mutex for 5ms every time the unlocked GPU
> idle wait succeeds. But the GPU idle wait itself is practically unbound
> which means the 5ms timeout might not be honoured.
>
> Cap the GPU idle wait
Quoting Tvrtko Ursulin (2019-01-09 14:12:47)
> From: Tvrtko Ursulin
>
> The code tries to grab struct mutex for 5ms every time the unlocked GPU
> idle wait succeeds. But the GPU idle wait itself is practically unbound
> which means the 5ms timeout might not be honoured.
The arbitrary timeout is
From: Tvrtko Ursulin
The code tries to grab struct mutex for 5ms every time the unlocked GPU
idle wait succeeds. But the GPU idle wait itself is practically unbound
which means the 5ms timeout might not be honoured.
Cap the GPU idle wait to 5ms as well to fix this.
v2:
* Rebase.
Signed-off-by
From: Tvrtko Ursulin
In two codepaths internal to the shrinker we know we will end up taking
the resursive mutex path.
It instead feels more elegant to avoid this altogether and not call
mutex_trylock_recursive in those cases.
We achieve this by extracting the shrinking part to __i915_gem_shrin
== Series Details ==
Series: drm/i915: Reduce i915_request_alloc retirement to local context (rev2)
URL : https://patchwork.freedesktop.org/series/54820/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
92c5dfde3ee9 drm/i915: Reduce i915_request_alloc retirement to local context
-
On 09/01/2019 13:14, Chris Wilson wrote:
In the continual quest to reduce the amount of global work required when
submitting requests, replace i915_retire_requests() after allocation
failure to retiring just our ring.
v2: Don't forget the list iteration included an early break, so we would
neve
== Series Details ==
Series: drm/i915: Try to sanitize bogus DPLL state left over by broken SNB
BIOSen
URL : https://patchwork.freedesktop.org/series/54942/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5383 -> Patchwork_11262
=
In the continual quest to reduce the amount of global work required when
submitting requests, replace i915_retire_requests() after allocation
failure to retiring just our ring.
v2: Don't forget the list iteration included an early break, so we would
never throttle on the last request in the ring/t
Hi, we've hit a snag with
commit 2b3e88ea65287ba738a798622405b15344871085
Author: Heiner Kallweit
Date: Sun Dec 16 18:30:14 2018 +0100
net: phy: improve phy state checking
as it is detecting that the call from tg3 during suspend is from the
HALTED state.
<4> [74.170194] [ cut
== Series Details ==
Series: series starting with [1/5] drm/i915/backlight: Restore backlight on
resume, v3. (rev2)
URL : https://patchwork.freedesktop.org/series/54896/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5382_full -> Patchwork_11261_full
==
Chris Wilson writes:
> Track the temporary wakerefs used within the selftests so that leaks are
> clear.
>
> Signed-off-by: Chris Wilson
> Cc: Jani Nikula
> ---
> drivers/gpu/drm/i915/selftests/huge_pages.c | 5 ++--
> drivers/gpu/drm/i915/selftests/i915_gem.c | 29 ---
>
On 09/01/2019 12:06, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-09 11:56:15)
On 07/01/2019 15:29, Chris Wilson wrote:
In the continual quest to reduce the amount of global work required when
submitting requests, replace i915_retire_requests() after allocation
failure to retiring just
>-Original Message-
>From: Brian Starkey [mailto:brian.star...@arm.com]
>Sent: Tuesday, January 8, 2019 7:43 PM
>To: Shankar, Uma
>Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>Lankhorst,
>Maarten ; Syrjala, Ville
>;
>Sharma, Shashank ; nd
>Subject: Re: [v6 1/
>-Original Message-
>From: Brian Starkey [mailto:brian.star...@arm.com]
>Sent: Tuesday, January 8, 2019 7:37 PM
>To: Shankar, Uma
>Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>Lankhorst,
>Maarten ; Syrjala, Ville
>;
>Sharma, Shashank ; nd
>Subject: Re: [v6 0/
From: Ville Syrjälä
Certain SNB machines (eg. ASUS K53SV) seem to have a broken BIOS
which misprograms the hardware badly when encountering a suitably
high resolution display. The programmed pipe timings are somewhat
bonkers and the DPLL is totally misprogrammed (P divider == 0).
That will result
>-Original Message-
>From: Roper, Matthew D
>Sent: Wednesday, January 9, 2019 1:15 AM
>To: Shankar, Uma
>Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Syrjala,
>Ville
>; emil.l.veli...@gmail.com; Lankhorst, Maarten
>
>Subject: Re: [v4 10/12] drm/i915: Add HLG EOT
Quoting Tvrtko Ursulin (2019-01-09 11:56:15)
>
> On 07/01/2019 15:29, Chris Wilson wrote:
> > In the continual quest to reduce the amount of global work required when
> > submitting requests, replace i915_retire_requests() after allocation
> > failure to retiring just our ring.
> >
> > References
On 07/01/2019 15:29, Chris Wilson wrote:
In the continual quest to reduce the amount of global work required when
submitting requests, replace i915_retire_requests() after allocation
failure to retiring just our ring.
References: 11abf0c5a021 ("drm/i915: Limit the backpressure for i915_request
Quoting Mika Kuoppala (2019-01-09 09:23:53)
> I should have been more specific. My concern was on documenting
> the changing return values.
The interface isn't documented, there's nothing in the header about the
functions? Where else would it be?
-Chris
Quoting Mika Kuoppala (2019-01-09 10:20:26)
> Chris Wilson writes:
> > @@ -1735,29 +1743,30 @@ static int i915_emon_status(struct seq_file *m,
> > void *unused)
> > struct drm_i915_private *dev_priv = node_to_i915(m->private);
> > struct drm_device *dev = &dev_priv->drm;
> > uns
Quoting Mika Kuoppala (2019-01-09 10:30:56)
> Chris Wilson writes:
>
> > Keep track of our wakeref used to keep the device awake so we can catch
> > any leak.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Jani Nikula
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 2 ++
> > drivers/gpu/drm/i915/
Chris Wilson writes:
> Keep track of the temporary rpm wakeref used for panel backlight access,
> so that we can cancel it immediately upon release and so more clearly
> identify leaks.
>
> Signed-off-by: Chris Wilson
> Cc: Jani Nikula
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915
Chris Wilson writes:
> Keep track of the temporary rpm wakeref inside hotplug detection, so
> that we can cancel it immediately upon release and so clearly identify
> leaks.
>
> Signed-off-by: Chris Wilson
> Cc: Jani Nikula
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/intel_hotpl
Chris Wilson writes:
> Keep track of the rpm wakeref used for framebuffer access so that we can
> cancel upon release and so more clearly identify leaks.
>
> Signed-off-by: Chris Wilson
> Cc: Jani Nikula
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/intel_display.c | 5 +++--
> dr
== Series Details ==
Series: series starting with [1/5] drm/i915/backlight: Restore backlight on
resume, v3. (rev2)
URL : https://patchwork.freedesktop.org/series/54896/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5382 -> Patchwork_11261
Chris Wilson writes:
> Keep track of the temporary rpm wakerefs used for user access to the
> device, so that we can cancel them upon release and clearly identify any
> leaks.
>
> Signed-off-by: Chris Wilson
> Cc: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_gem.c| 47
Quoting Kenneth Graunke (2019-01-09 09:02:35)
> Does it work if you emit 3DSTATE_GLOBAL_DEPTH_OFFSET_CLAMP after
> MI_SET_CONTEXT? That was the source of most CONSTANT_BUFFER hangs
> I saw on Broadwater/Crestline. Notably, it's also a bug that was
> fixed on Eaglelake/Cantiga...
Thanks for the s
Chris Wilson writes:
> Keep track of our acquired wakeref for interacting with the guc, so that
> we can cancel it upon release and so clearly identify leaks.
>
> Signed-off-by: Chris Wilson
> Cc: Jani Nikula
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/intel_guc_log.c | 15 +
== Series Details ==
Series: MST refcounting/atomic helpers cleanup (rev5)
URL : https://patchwork.freedesktop.org/series/54030/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5380_full -> Patchwork_11258_full
Summary
--
Chris Wilson writes:
> Track the wakeref used for temporary access to the device, and discard
> it upon release so that leaks can be identified.
>
> Signed-off-by: Chris Wilson
> Cc: Jani Nikula
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_pmu.c | 26 +---
1 - 100 of 120 matches
Mail list logo
