On 17/01/2019 23:31, Chris Wilson wrote:
The motivation for introducing the check that we only enable breadcrumb
irqs if the device's irq was installed was once upon a time we waited
during suspend after disabling interrupts (which was quite slow until
the bug was discovered). Since then we
== Series Details ==
Series: drm: Split out drm_probe_helper.h (rev4)
URL : https://patchwork.freedesktop.org/series/55232/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5441_full -> Patchwork_11974_full
Summary
---
== Series Details ==
Series: drm/i915/icl: Adding few more device IDs for Ice Lake
URL : https://patchwork.freedesktop.org/series/55393/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5444 -> Patchwork_11978
Summary
---
== Series Details ==
Series: icl: Misc PLL patches
URL : https://patchwork.freedesktop.org/series/55378/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5440_full -> Patchwork_11972_full
Summary
---
**SUCCESS**
No
We just got aware that there was more IDs available
at spec, so let's add them already.
Cc: James Ausmus
Cc: José Roberto de Souza
Signed-off-by: Rodrigo Vivi
---
include/drm/i915_pciids.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/drm/i915_pciids.h
== Series Details ==
Series: drm/i915: Fix wakeref cookie handling in debugfs/i915_forcewake_user
URL : https://patchwork.freedesktop.org/series/55366/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5440_full -> Patchwork_11971_full
== Series Details ==
Series: drm/i915/breadcrumbs: Drop assertion that we've already enabled irqs
URL : https://patchwork.freedesktop.org/series/55388/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5443 -> Patchwork_11977
Performing a GPU reset clobbers the fence registers, affecting which
addresses the tiled GTT mmap access. If the driver does not take
precautions across a GPU reset, a client may read the wrong values (but
only within their own buffer as the fence will only be degraded to
I915_TILING_NONE,
== Series Details ==
Series: drm/i915/selftests: Query the vm under test for hugepage support (rev2)
URL : https://patchwork.freedesktop.org/series/55386/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5442 -> Patchwork_11976
Quoting Patchwork (2019-01-17 23:36:23)
> Possible regressions
>
> * igt@gem_mmap_gtt@hang:
> - shard-snb: PASS -> FAIL
The only thing unexpected here is that they all didn't fail. (Dropping
this protection of disabling memory access while the fence registers are
being
== Series Details ==
Series: series starting with [01/23] drm/i915: Make all GPU resets atomic
URL : https://patchwork.freedesktop.org/series/55365/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5440_full -> Patchwork_11970_full
The motivation for introducing the check that we only enable breadcrumb
irqs if the device's irq was installed was once upon a time we waited
during suspend after disabling interrupts (which was quite slow until
the bug was discovered). Since then we have the notion of pinning the
breadcrumb irq,
Quoting Tvrtko Ursulin (2019-01-17 16:23:48)
>
> On 16/01/2019 17:01, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-01-16 16:47:43)
> >>
> >> On 07/01/2019 11:54, Chris Wilson wrote:
> >>> @@ -1530,20 +1531,21 @@ i915_gem_pwrite_ioctl(struct drm_device *dev,
> >>> void *data,
> >>>
>
Since we have the ppgtt we want to test, we can ask it directly if it is
suitable for the hugepage test we intend to undertake.
v2: Not everyone has full-ppgtt
Signed-off-by: Chris Wilson
Cc: Matthew Auld
---
drivers/gpu/drm/i915/selftests/huge_pages.c | 2 +-
1 file changed, 1 insertion(+),
== Series Details ==
Series: drm/i915/selftests: Query the vm under test for hugepage support
URL : https://patchwork.freedesktop.org/series/55386/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5441 -> Patchwork_11975
Since we have the ppgtt we want to test, we can ask it directly if it is
suitable for the hugepage test we intend to undertake.
Signed-off-by: Chris Wilson
Cc: Matthew Auld
---
drivers/gpu/drm/i915/selftests/huge_pages.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
struct clocksource *clock;
unsigned long flags;
+ pr_info("## timekeeping_init() \n");
+
Guenter
---
# bad: [a37d50ca3b837c19a297f349365d11a20c1087d0] Add linux-next specific files
for 20190117
# good: [1c7fc5cbc33980acd13d
== Series Details ==
Series: drm: Split out drm_probe_helper.h (rev4)
URL : https://patchwork.freedesktop.org/series/55232/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5441 -> Patchwork_11974
Summary
---
On Thu, Jan 17, 2019 at 12:21 PM Lucas De Marchi
wrote:
>
> Right now when searching for shared plls we mandate that they have
> consecutive IDs since we just pass the min and max id and loop over the
> range. However the IDs can't be arbitrarily defined since they are used
> as index to the MMIO
== Series Details ==
Series: drm: Split out drm_probe_helper.h (rev4)
URL : https://patchwork.freedesktop.org/series/55232/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
6b67170fc382 drm: Split out drm_probe_helper.h
-:686: WARNING:OBSOLETE: drivers/gpu/drm/cirrus/cirrus_drv.c
== Series Details ==
Series: drm/i915: introduce macros to define register contents (rev2)
URL : https://patchwork.freedesktop.org/series/50513/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5440_full -> Patchwork_11969_full
== Series Details ==
Series: series starting with [v4,1/4] drm/i915/psr: Allow PSR2 to be enabled
when debugfs asks
URL : https://patchwork.freedesktop.org/series/55379/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5440 -> Patchwork_11973
== Series Details ==
Series: series starting with [v4,1/4] drm/i915/psr: Allow PSR2 to be enabled
when debugfs asks
URL : https://patchwork.freedesktop.org/series/55379/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
5e4082ef6525 drm/i915/psr: Allow PSR2 to be enabled when
== Series Details ==
Series: icl: Misc PLL patches
URL : https://patchwork.freedesktop.org/series/55378/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5440 -> Patchwork_11972
Summary
---
**SUCCESS**
No
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
v3:
- reading PSR2_SU_STATUS registers together(Dhinakaran)
- printing SU blocks of frames with 0
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 frontbuffer bits: 0x000
Main link in standby mode: no
HW Enabled & Active bit: yes
This register contains how many blocks was sent in the past selective
updates.
Those registers are not kept set all the times but polling it after flip
can show the values corresponding to the last 8 frames.
v2: Improved macros(Dhinakaran)
Cc: Rodrigo Vivi
Cc: Dhinakaran Pandiyan
Reviewed-by:
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 enabled needs to take in consideration
the debug field.
v2: Using the
On Wed, 2019-01-16 at 14:37 -0800, Dhinakaran Pandiyan wrote:
> On Fri, 2019-01-11 at 12:44 -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:
> > -
I tried to narrow down the issue further and my current understanding
is that the Skylake driver performs link reset operations without the
display power turned on - which does not look like a very smart thing
to do in hindsight.
In other words, it's not really when snd_hdac_i915_init() is
== Series Details ==
Series: icl: Misc PLL patches
URL : https://patchwork.freedesktop.org/series/55378/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
bc90321eb832 drm/i915/icl: use tc_port in MG_PLL macros
-:183: WARNING:LINE_SPACING: Missing a blank line after declarations
On Thu, 17 Jan 2019 20:53:06 +0100,
Pierre-Louis Bossart wrote:
>
>
> > I could use some feedback on HDMI audio issues exposed during the
> > 4.21 merge window. By accident (misleading documentation) we ended
> > up enabling the Skylake driver instead of the HDaudio legacy, and
> > broke audio
Right now when searching for shared plls we mandate that they have
consecutive IDs since we just pass the min and max id and loop over the
range. However the IDs can't be arbitrarily defined since they are used
as index to the MMIO address, hence dependent on what the hardware
implements.
This
We should not pass DPLL_ID_ICL_DPLL0 or DPLL_ID_ICL_DPLL1 to this
function because the path is only taken for non-combophy ports. Let the
warning trigger if improper value is given.
While at it, rename the function to match the register name we are
trying to program.
Signed-off-by: Lucas De
Some PLL reworks on ICL. Patches are more or less independent of each
other, but touch the same part of the code.
Lucas De Marchi (5):
drm/i915/icl: use tc_port in MG_PLL macros
drm/i915: always return something
drm/i915/icl: remove dpll from clk_sel
drm/i915/icl: keep track of unused pll
Instead of looping again on the range of plls, just keep track of one
unused one and use it later.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/intel_dpll_mgr.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git
Even if we don't have the correct clock and get a warning, we should not
skip the return.
Fixes: 1fa11ee2d9d0 ("drm/i915/icl: start adding the TBT pll")
Cc: Paulo Zanoni
Cc: # v4.19+
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/intel_ddi.c | 2 +-
1 file changed, 1 insertion(+), 1
Fix the TODO leftover in the code by changing the argument in MG_PLL
macros. The MG_PLL ids used to access the register values can be
converted from tc_port rather than port.
The helper functions were also renamed to use "tc" as prefix to make
them more generic.
Signed-off-by: Lucas De Marchi
I could use some feedback on HDMI audio issues exposed during the 4.21
merge window. By accident (misleading documentation) we ended up
enabling the Skylake driver instead of the HDaudio legacy, and broke
audio on a number of Skylake and ApolloLake devices where the
HDMI/iDISP codec was not
On Thu, Jan 17, 2019 at 11:13:58AM -0800, Matt Roper wrote:
> On Fri, Jan 11, 2019 at 07:08:23PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Planes scanning out C8 will want to use the legacy lut as
> > their palette. That means the LUT content are unikely to
> > be useful for
On Fri, Jan 11, 2019 at 07:08:23PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Planes scanning out C8 will want to use the legacy lut as
> their palette. That means the LUT content are unikely to
> be useful for gamma correction on other planes. Thus we
> should disable pipe gamma for
On Fri, Jan 11, 2019 at 07:08:22PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> As with pipe gamma we can avoid the potential precision loss from
> the pipe csc unit when there is no need to use it. And again
> we need the same logic for updating the planes.
>
> Signed-off-by: Ville
On Thu, Jan 17, 2019 at 10:40:23AM -0800, Matt Roper wrote:
> On Fri, Jan 11, 2019 at 07:08:21PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > The pipe internal precision is higher than what we currently program to
> > the degamma/gamma LUTs. We can get a higher quality image by
On Fri, Jan 11, 2019 at 07:08:21PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The pipe internal precision is higher than what we currently program to
> the degamma/gamma LUTs. We can get a higher quality image by bypassing
> the LUTs when they're not needed. Let's do that.
>
> Each
On 01/17/2019 06:24 AM, Mika Kuoppala wrote:
Chris Wilson writes:
The guc (and huc) currently inexcruitably depend on struct_mutex for
device reinitialisation from inside the reset, and indeed taking any
mutex here is verboten (as we must be able to reset from underneath any
of our
On Wed, Jan 16, 2019 at 03:43:20PM -0800, José Roberto de Souza wrote:
> If the sink and source supports HBR3, TP4 should be used as link
> training pattern.
> For PSR2 there is no register to set and enable TP4 but according to
> eDP spec TP3 is still a training pattern acceptable for HBR3
On 17/01/2019 16:52, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-17 16:44:54)
On 17/01/2019 14:34, Chris Wilson wrote:
Since commit d4ccceb05591 ("drm/i915/icl: Ringbuffer interrupt handling")
we have required a mechanism to avoid touching the interrupt hardware
for breadcrumbs,
On 17/01/2019 14:34, Chris Wilson wrote:
Currently, the list of timelines is serialised by the struct_mutex, but
to alleviate difficulties with using that mutex in future, move the
list management under its own dedicated mutex.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h
On Thu, Jan 17, 2019 at 05:45:41PM +0100, Daniel Vetter wrote:
> On Wed, Jan 16, 2019 at 07:10:18PM +0100, Sam Ravnborg wrote:
> > Hi Daniel.
> >
> > > v5: Actually try to sort them, and while at it, sort all the ones I
> > > touch.
> >
> > Applied this variant on top of drm-misc and did a build
On 17/01/2019 14:34, Chris Wilson wrote:
The evict selftests presumed that all objects in use had been allocated
by itself. This is a dubious claim and so instead of asserting complete
control over the object lists, take (temporary) ownership of them
instead.
Signed-off-by: Chris Wilson
---
== Series Details ==
Series: drm/i915: Fix wakeref cookie handling in debugfs/i915_forcewake_user
URL : https://patchwork.freedesktop.org/series/55366/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5440 -> Patchwork_11971
Quoting Tvrtko Ursulin (2019-01-17 16:44:54)
>
> On 17/01/2019 14:34, Chris Wilson wrote:
> > Since commit d4ccceb05591 ("drm/i915/icl: Ringbuffer interrupt handling")
> > we have required a mechanism to avoid touching the interrupt hardware
> > for breadcrumbs, superseding our mock interface
On 17/01/2019 16:36, Chris Wilson wrote:
Quoting Chris Wilson (2019-01-17 16:31:27)
Quoting Tvrtko Ursulin (2019-01-17 16:27:04)
On 17/01/2019 14:34, Chris Wilson wrote:
Remove the struct_mutex requirement for looking up the vma for an
object.
Another patch with missing change log.
On Wed, Jan 16, 2019 at 07:10:18PM +0100, Sam Ravnborg wrote:
> Hi Daniel.
>
> > v5: Actually try to sort them, and while at it, sort all the ones I
> > touch.
>
> Applied this variant on top of drm-misc and did a build test.
> Looked good for ia64, x86 and alpha.
>
> Took a closer look at the
Quoting Tvrtko Ursulin (2019-01-17 16:27:04)
>
> On 17/01/2019 14:34, Chris Wilson wrote:
> > Remove the struct_mutex requirement for looking up the vma for an
> > object.
>
> Another patch with missing change log.
>
> I see that you at least fixed the tree typo since the round I last
>
On 17/01/2019 14:34, Chris Wilson wrote:
Since commit d4ccceb05591 ("drm/i915/icl: Ringbuffer interrupt handling")
we have required a mechanism to avoid touching the interrupt hardware
for breadcrumbs, superseding our mock interface for selftests.
References: d4ccceb05591 ("drm/i915/icl:
Quoting Chris Wilson (2019-01-17 16:31:27)
> Quoting Tvrtko Ursulin (2019-01-17 16:27:04)
> >
> > On 17/01/2019 14:34, Chris Wilson wrote:
> > > Remove the struct_mutex requirement for looking up the vma for an
> > > object.
> >
> > Another patch with missing change log.
>
> There was no
On Wed, Jan 16, 2019 at 05:11:26PM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> >Ville Syrjälä
> >Sent: Tuesday, January 15, 2019 12:42 AM
> >To: Roper, Matthew D
> >Cc:
Quoting Tvrtko Ursulin (2019-01-17 16:27:04)
>
> On 17/01/2019 14:34, Chris Wilson wrote:
> > Remove the struct_mutex requirement for looking up the vma for an
> > object.
>
> Another patch with missing change log.
There was no functional change.
> I see that you at least fixed the tree typo
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag,
fixing commit: 516a49cc1946 drm/i915: Fix assert_plane() warning on bootup with
external display.
The bot has tested the following trees: v4.20.2.
v4.20.2: Failed to apply! Possible
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag,
fixing commit: 516a49cc1946 drm/i915: Fix assert_plane() warning on bootup with
external display.
The bot has tested the following trees: v4.20.2.
v4.20.2: Failed to apply! Possible
On 17/01/2019 14:34, Chris Wilson wrote:
Remove the struct_mutex requirement for looking up the vma for an
object.
Another patch with missing change log.
I see that you at least fixed the tree typo since the round I last
reviewed. But I also had some other questions which I did not see you
On 16/01/2019 17:01, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-16 16:47:43)
On 07/01/2019 11:54, Chris Wilson wrote:
@@ -1530,20 +1531,21 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void
*data,
static void i915_gem_object_bump_inactive_ggtt(struct drm_i915_gem_object
== Series Details ==
Series: series starting with [1/4] drm/i915/vbt: Add 'tp4' to varibles holding
TP2/3/4 PSR wakeup time
URL : https://patchwork.freedesktop.org/series/55340/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5439_full -> Patchwork_11968_full
Hi,
On Wed, Jan 16, 2019 at 05:33:19PM -0800, Dhinakaran Pandiyan wrote:
> On Thu, 2018-12-20 at 17:52 +0200, Imre Deak wrote:
> > VBT may include incorrect information about the presence of port F.
> > Work
> > around this on SKUs where we know the port is not present.
>
> If we cannot trust
== Series Details ==
Series: series starting with [01/23] drm/i915: Make all GPU resets atomic
URL : https://patchwork.freedesktop.org/series/55365/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5440 -> Patchwork_11970
Quoting Ville Syrjälä (2019-01-17 15:07:53)
> On Wed, Jan 16, 2019 at 03:54:21PM +, Chris Wilson wrote:
> > Let static analyzers (smatch) know that we are not going to wander off
> > the end of the array by providing a tight upper bound:
> >
> > drivers/gpu/drm/i915/intel_display.c:9532
On Wed, Jan 16, 2019 at 03:54:21PM +, Chris Wilson wrote:
> Let static analyzers (smatch) know that we are not going to wander off
> the end of the array by providing a tight upper bound:
>
> drivers/gpu/drm/i915/intel_display.c:9532 hsw_get_transcoder_state() error:
> buffer overflow
== Series Details ==
Series: series starting with [01/23] drm/i915: Make all GPU resets atomic
URL : https://patchwork.freedesktop.org/series/55365/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Make all GPU resets atomic
Okay!
Commit:
On Wed, Jan 16, 2019 at 09:38:59AM -0800, Matt Roper wrote:
> On Fri, Jan 11, 2019 at 07:08:17PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > The LUTs are single buffered so we should program them after
> > the double buffered pipe updates have been latched by the
> > hardware.
>
On Thu, Jan 17, 2019 at 05:14:06AM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: Roper, Matthew D
> >Sent: Thursday, January 17, 2019 1:07 AM
> >To: Ville Syrjala
> >Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma
> >Subject: Re: [PATCH 09/13] drm/i915: Track pipe
== Series Details ==
Series: series starting with [01/23] drm/i915: Make all GPU resets atomic
URL : https://patchwork.freedesktop.org/series/55365/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
cc34d0c113bf drm/i915: Make all GPU resets atomic
-:23: CHECK:USLEEP_RANGE:
Quoting Tvrtko Ursulin (2019-01-17 14:48:31)
> From: Tvrtko Ursulin
>
> To avoid a false positive of a leaked wakeref, we can store the cookie
> in file->private_data and use it in intel_runtime_pm_put.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Chris Wilson
> ---
>
From: Tvrtko Ursulin
To avoid a false positive of a leaked wakeref, we can store the cookie
in file->private_data and use it in intel_runtime_pm_put.
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 5 +++--
1 file changed, 3 insertions(+), 2
I wrote something here like...
Just the early part of the series with the HWSP allocation changes
suggested by John. Tvrtko I haven't applied your mutex feedback yet.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
Remove the struct_mutex requirement for looking up the vma for an
object.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 6 +--
drivers/gpu/drm/i915/i915_gem.c | 33 +++--
drivers/gpu/drm/i915/i915_gem_object.h| 45 ++---
In preparation for the next few commits, make resetting the GPU atomic.
Currently, we have prepared gen6+ for atomic resetting of individual
engines, but now there is a requirement to perform the whole device
level reset (just the register poking) from inside an atomic context.
Signed-off-by:
Allocate a page for use as a status page by a group of timelines, as we
only need a dword of storage for each (rounded up to the cacheline for
safety) we can pack multiple timelines into the same page. Each timeline
will then be able to track its own HW seqno.
v2: Reuse the common per-engine HWSP
Currently, the list of timelines is serialised by the struct_mutex, but
to alleviate difficulties with using that mutex in future, move the
list management under its own dedicated mutex.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 5 +-
Now that the submission backends are controlled via their own spinlocks,
with a wave of a magic wand we can lift the struct_mutex requirement
around GPU reset. That is we allow the submission frontend (userspace)
to keep on submitting while we process the GPU reset as we can suspend
the backend
The guc (and huc) currently inexcruitably depend on struct_mutex for
device reinitialisation from inside the reset, and indeed taking any
mutex here is verboten (as we must be able to reset from underneath any
of our mutexes). That makes recovering the guc unviable without, for
example, reserving
The evict selftests presumed that all objects in use had been allocated
by itself. This is a dubious claim and so instead of asserting complete
control over the object lists, take (temporary) ownership of them
instead.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/selftests/i915_gem_evict.c
Previously we only accommodated having a vma pinned by a small number of
users, with the maximum being pinned for use by the display engine. As
such, we used a small bitfield only large enough to allow the vma to
be pinned twice (for back/front buffers) in each scanout plane. Keeping
the maximum
A starting point to counter the pervasive struct_mutex. For the goal of
avoiding (or at least blocking under them!) global locks during user
request submission, a simple but important step is being able to manage
each clients GTT separately. For which, we want to replace using the
struct_mutex as
Always perform the requested reset, even if we believe the engine is
idle. Presumably there was a reason the caller wanted the reset, and in
the near future we lose the easy tracking for whether the engine is
idle.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_reset.c |
Since commit d4ccceb05591 ("drm/i915/icl: Ringbuffer interrupt handling")
we have required a mechanism to avoid touching the interrupt hardware
for breadcrumbs, superseding our mock interface for selftests.
References: d4ccceb05591 ("drm/i915/icl: Ringbuffer interrupt handling")
Signed-off-by:
Our goal is to remove struct_mutex and replace it with fine grained
locking. One of the thorny issues is our eviction logic for reclaiming
space for an execbuffer (or GTT mmaping, among a few other examples).
While eviction itself is easy to move under a per-VM mutex, performing
the activity
Trim the struct_mutex hold and exclude the call to i915_gem_set_wedged()
as a reminder that it must be callable without struct_mutex held.
Signed-off-by: Chris Wilson
Cc: Michal Wajdeczko
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 6 +++---
1 file changed, 3
To correctly simulate preemption between contexts, we need independent
timelines along each context. Make it so.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/selftests/mock_engine.c | 90 ++--
1 file changed, 47 insertions(+), 43 deletions(-)
diff --git
Keep track of partially allocated pages for use in allocating future
timeline HWSP. This is still without migration, so it is possible for
the system to end up with each timeline in its own page, but we ensure
that no new allocation would needless allocate a fresh page!
Signed-off-by: Chris
Currently we only allocate an object and vma if we are using a GGTT
virtual HWSP, and a plain struct page for a physical HWSP. For
convenience later on with global timelines, it will be useful to always
have the status page being tracked by a struct i915_vma. Make it so.
Signed-off-by: Chris
A few years ago, see commit 688e6c725816 ("drm/i915: Slaughter the
thundering i915_wait_request herd"), the issue of handling multiple
clients waiting in parallel was brought to our attention. The
requirement was that every client should be woken immediately upon its
request being signaled,
Missed breadcrumb detection is defunct due to the tight coupling with
dma_fence signaling and the myriad ways we may signal fences from
everywhere but from an interrupt, i.e. we frequently signal a fence
before we even see its interrupt. This means that even if we miss an
interrupt for a fence, it
To allow requests to forgo a common execution timeline, one question we
need to be able to answer is "is this request running?". To track
whether a request has started on HW, we can emit a breadcrumb at the
beginning of the request and check its timeline's HWSP to see if the
breadcrumb has
The global seqno is defunct and so we have no meaningful indicator of
forward progress for an engine. You need to listen to the request
signaling tracepoints instead.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_irq.c | 2 --
drivers/gpu/drm/i915/i915_trace.h | 25
Supplement the per-engine HWSP with a per-timeline HWSP. That is a
per-request pointer through which we can check a local seqno,
abstracting away the presumption of a global seqno. In this first step,
we point each request back into the engine's HWSP so everything
continues to work with the global
If we restrict ourselves to only using a cacheline for each timeline's
HWSP (we could go smaller, but want to avoid needless polluting
cachelines on different engines between different contexts), then we can
suballocate a single 4k page into 64 different timeline HWSP. By
treating each fresh
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Now that we have allocated ourselves a cacheline to store a breadcrumb,
we can emit a write from the GPU into the timeline's HWSP of the
per-context seqno as we complete each request. This drops the mirroring
of the per-engine HWSP and allows each context to operate independently.
We do not need
Chris Wilson writes:
> The guc (and huc) currently inexcruitably depend on struct_mutex for
> device reinitialisation from inside the reset, and indeed taking any
> mutex here is verboten (as we must be able to reset from underneath any
> of our mutexes). That makes recovering the guc unviable
1 - 100 of 138 matches
Mail list logo
