This simplifies adding new query item objects.
Signed-off-by: Abdiel Janulgue
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_query.c | 40 ---
1 file changed, 26 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_query.c
b/drivers/gpu/drm/i915
== Series Details ==
Series: Per context dynamic (sub)slice power-gating (rev12)
URL : https://patchwork.freedesktop.org/series/48194/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5379_full -> Patchwork_11256_full
Summary
== Series Details ==
Series: drm/i915/query: Split out query item checks
URL : https://patchwork.freedesktop.org/series/54917/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
743f34f1ebba drm/i915/query: Split out query item checks
-:19: ERROR:POINTER_LOCATION: "foo* bar" should
On Tue, 08 Jan 2019, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: drop all drmP.h includes
> URL : https://patchwork.freedesktop.org/series/54859/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_5373_full -> Patchwork_11207_full
> ===
== Series Details ==
Series: drm/i915/query: Split out query item checks
URL : https://patchwork.freedesktop.org/series/54917/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5380 -> Patchwork_11260
Summary
---
**FAILU
On Tuesday, January 8, 2019 5:02:59 PM PST Chris Wilson wrote:
> Quoting Chris Wilson (2019-01-08 12:28:18)
> > Broadwater and the rest of gen4 do support being able to saving and
> > reloading context specific registers between contexts, providing isolation
> > of the basic GPU state (as programm
Chris Wilson writes:
> Quoting Mika Kuoppala (2019-01-08 16:23:18)
>> > @@ -3965,7 +4014,7 @@ void intel_power_domains_init_hw(struct
>> > drm_i915_private *dev_priv, bool resume)
>> > void intel_power_domains_fini_hw(struct drm_i915_private *dev_priv)
>> > {
>> > /* Keep the power well
On 09/01/2019 07:51, Abdiel Janulgue wrote:
This simplifies adding new query item objects.
Signed-off-by: Abdiel Janulgue
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_query.c | 40 ---
1 file changed, 26 insertions(+), 14 deletions(-)
diff --git a/drivers/
Hi,
On 08-01-19 18:33, Andy Shevchenko wrote:
On Tue, Jan 08, 2019 at 04:35:45PM +0100, Hans de Goede wrote:
Hi,
On 08-01-19 15:51, Andy Shevchenko wrote:
On Tue, Jan 08, 2019 at 02:45:39PM +0100, Hans de Goede wrote:
On 07-01-19 16:46, Andy Shevchenko wrote:
On Mon, Jan 07, 2019 at 12:15:5
== Series Details ==
Series: series starting with [1/4] drm/edid: Pass connector to AVI infoframe
functions
URL : https://patchwork.freedesktop.org/series/54903/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5379_full -> Patchwork_11257_full
==
Quoting Tvrtko Ursulin (2019-01-09 09:25:49)
>
> On 09/01/2019 07:51, Abdiel Janulgue wrote:
> > This simplifies adding new query item objects.
> >
> > Signed-off-by: Abdiel Janulgue
> > Cc: Joonas Lahtinen
> > ---
> > drivers/gpu/drm/i915/i915_query.c | 40 ---
> >
Hi,
On 07-01-19 16:31, Ville Syrjälä wrote:
On Mon, Jan 07, 2019 at 12:15:56PM +0100, Hans de Goede wrote:
Add support for PMIC MIPI sequences using the new
intel_soc_pmic_exec_mipi_pmic_seq_element function.
This fixes the DSI LCD panel not lighting up when not initialized by the
GOP (because
On 25.9.2018 22.37, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Another gtt remapping posting.
>
> Changes since the last time:
> - split out the plane stride check function (already in)
> - use add_overflows() (after massaging it a bit)
> - include some selftests for the remapped/rotated vma
Chris Wilson writes:
> Record the wakeref used for keeping the device awake as the GPU is
> executing requests and be sure to cancel the tracking upon parking.
>
> Signed-off-by: Chris Wilson
> Cc: Jani Nikula
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 +-
> dri
Chris Wilson writes:
> Keep hold of the local wakeref used in error handling, to cancel
> the tracking 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_irq.c | 5 +++--
> 1 file chang
Chris Wilson writes:
> As sysfs has a simple pattern of taking a rpm wakeref around the user
> access, we can track the local reference and drop it as soon as
> possible.
>
> Signed-off-by: Chris Wilson
> Cc: Jani Nikula
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_sysfs.c |
Chris Wilson writes:
> As debugfs has a simple pattern of taking a rpm wakeref around the user
> access, we can track the local reference and drop it as soon as
> possible.
>
> Signed-off-by: Chris Wilson
> Cc: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 135 +
== 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 : warning
== Summary ==
$ dim checkpatch origin/drm-tip
0cd0b789cc0b drm/i915/backlight: Restore backlight on resume,
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/i915_perf.c | 10 +-
> 2 files changed, 7 insertions(+),
== 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 : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/backlight: Restore backli
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 +---
== 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:
> 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 +
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 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
== 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 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
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 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
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/
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 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
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 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
>-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
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: 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/
>-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/
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
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 ---
>
== 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
==
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
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
== 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
=
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: 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
-
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
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
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
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
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
== 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
== 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
=
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
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
== 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
===
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
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),
== 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
== 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: 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
===
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: 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
===
== 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 : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5383_full -> Patchwork_11265_full
=
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
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
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
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
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
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
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
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
== 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.
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
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
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
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
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
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
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
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 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
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
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
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
== 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
== 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
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: 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: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: 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
== 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
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
1 - 100 of 120 matches
Mail list logo
