Move the debug pretty printer into a standalone routine prior to
extending it in upcoming feature work.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_engine_cs.c | 55 ++--
drivers/gpu/drm/i915/intel_lrc.c | 58 +
Hi,
This series has not been recognized by Patchwork as such, nor are the
patches numbered. Have you used git format-patch - --cover-letter and
git send-email to send it out?
Rest inline.
On 05/01/2019 02:39, Carlos Santa wrote:
From: Michel Thierry
*** General ***
Watchdog timeout (or
Ignore trying to shrink from i915 if we fail to acquire the struct_mutex
in the shrinker while performing direct-reclaim. The trade-off being
(much) lower latency for non-i915 clients at an increased risk of being
unable to obtain a page from direct-reclaim without hitting the
oom-notifier. The pro
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
---
drivers/gpu/drm/i915/i915_sysfs.c | 24 ++--
1 file changed, 14 insertions(+), 10 d
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 around cookies provided
by the various rpm_get
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
---
drivers/gpu/drm/i915/intel_display.c | 5 +++--
drivers/gpu/drm/i915/intel_fbdev.c | 9 +
2 files changed, 8
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 to
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 c
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 around cookies provided
by the various rpm_get
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 Wilso
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 t
Everytime we take a wakeref, record the stack trace of where it was
taken; clearing the set if we ever drop back to no owners. For debugging
a rpm leak, we can look at all the current wakerefs and check if they
have a matching rpm_put.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
---
drivers/gpu
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
---
drivers/gpu/drm/i915/intel_hotplug.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
dif
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 pe
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
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 ++---
drivers/gp
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 advanced
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: Chri
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 | 1 +
drivers/gpu/drm/i915/i9
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 tracki
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 a/drivers/gpu/drm
Currently Ironlake operates under the assumption that rpm awake (and its
error checking is disabled). As such, we have missed a few places where we
access registers without taking the rpm wakeref and thus trigger
warnings. intel_ips being one culprit.
As this involved adding a potentially sleeping
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 ---
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
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_gem.c | 11 +++
2 files changed, 8 in
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
---
drivers/gpu/drm/i915/intel_guc_log.c | 15 +--
drivers/gpu/drm/i915/intel_huc.c | 5 +++--
2 fil
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 ---
.../drm/i915/selftests/i915_gem_cohere
Currently the code to reset the GPU and our state is spread widely
across a few files. Pull the logic together into a common file.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Makefile |3 +-
drivers/gpu/drm/i915/i915_debugfs.c |2 +
drivers/gpu/drm/i915
Track where and when we acquire and release the power well for pps
access along the dp aux link, with a view to detecting if we leak any
wakerefs.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 231 +---
1 file changed, 121 insertio
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
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 ind
On module load and unload, we grab the POWER_DOMAIN_INIT powerwells and
transfer them to the runtime-pm code. We can use our wakeref tracking to
verify that the wakeref is indeed passed from init to enable, and
disable to fini; and across suspend.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
---
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
---
drivers/gpu/drm/i915/i915_pmu.c | 26 +-
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a
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
---
drivers/gpu/drm/i915/i915_irq.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i9
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(+), 5 deletions(-)
diff --git a/drivers/gp
As we only release each power well once, we assume that each transcoder
maps to a different domain. Complain if this is not so.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
---
drivers/gpu/drm/i915/intel_display.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/int
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, without
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 +-
drivers/gpu/drm/i915/i915_
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 +---
1 file changed, 82 insertions
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 |
We have two classes of VM, global GTT and per-process GTT. In order to
allow ourselves the freedom to mix both along call chains, distinguish
the two classes with regards to their mutex and lockdep maps.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 10 +-
d
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
As the GT_IRQ power domain implies a wakeref, we can use it inplace of
our existing redundant rpm grab.
Signed-off-by: Chris Wilson
Cc: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/i915_gem.c | 11 ---
drivers/gpu/drm/i91
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: Ch
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: Chris Wilson
Cc: Jani Nikula
---
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
---
drivers/gpu/drm/i915/intel_panel.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletio
Include the total size of closed vma when reporting the per_ctx_stats of
debugfs/i915_gem_objects.
Whilst adjusting the context tracking, note that we can simply use our
list of contexts in i915->contexts rather than circumlocute via
dev->filelist and the per-file context idr, with the result that
Quoting Mika Kuoppala (2019-01-07 11:21:32)
> Chris Wilson writes:
>
> > Haswell also requires the RING_IMR flush for its unique vebox setup to
> > avoid losing interrupts, as per 476af9c26063 ("drm/i915/gen6: Flush
> > RING_IMR changes before changing the global GT IMR"):
> >
> > On Baytail, not
On Mon, Jan 07, 2019 at 11:12:30AM +, Tvrtko Ursulin wrote:
>
> On 07/01/2019 11:01, Petri Latvala wrote:
> > On Fri, Jan 04, 2019 at 03:37:09PM +, Tvrtko Ursulin wrote:
> > > diff --git a/tests/intel-ci/blacklist.txt b/tests/intel-ci/blacklist.txt
> > > index 73d127603d28..d76a4b3b1c71 10
If we do not know the underlying swizzle on the HW, we do not know the
full tiling pattern and cannot predict the expected results. This is
often because the swizzle varies between pages and is not as constant as
we naively expected.
Signed-off-by: Chris Wilson
---
tests/i915/gem_tiled_pread_bas
Chris Wilson writes:
> Haswell also requires the RING_IMR flush for its unique vebox setup to
> avoid losing interrupts, as per 476af9c26063 ("drm/i915/gen6: Flush
> RING_IMR changes before changing the global GT IMR"):
>
> On Baytail, notably, we can still detect missed interrupt syndrome
> (whe
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 an external monitor was connected) on GPD win and GPD pocket
devices.
Specifically the LCD panel seems to nee
Most PMIC-s use only a single i2c-address, so after verifying the
i2c-address matches, we can simply pass the call to regmap_update_bits.
This commit adds support for this and hooks this up for the xpower AXP288
PMIC by setting the new pmic_i2c_address field.
This fixes the following errors on di
Implement the exec_mipi_pmic_seq_element callback for the CHT Whiskey Cove
PMIC.
On some CHT devices this fixes the LCD panel not lighting up when it was
not initialized by the GOP, because an external monitor was plugged in and
the GOP initialized only the external monitor.
Reviewed-by: Mika Wes
Hi All,
This patch-set has been on the list for a while now, it would be nice
if we can get this merged. I already have an ack for merging the ACPI
bits through drm-intel-next-queued, so we really need an ack for
the last 2 patches from one of the intel-gfx folks so that I can push
this to dinq.
DSI LCD panels describe an initialization sequence in the Video BIOS
Tables using so called MIPI sequences. One possible element in these
sequences is a PMIC specific element of 15 bytes.
Although this is not really an ACPI opregion, the ACPI opregion code is the
closest thing we have. We need to
On 07/01/2019 11:01, Petri Latvala wrote:
On Fri, Jan 04, 2019 at 03:37:09PM +, Tvrtko Ursulin wrote:
diff --git a/tests/intel-ci/blacklist.txt b/tests/intel-ci/blacklist.txt
index 73d127603d28..d76a4b3b1c71 100644
--- a/tests/intel-ci/blacklist.txt
+++ b/tests/intel-ci/blacklist.txt
@@ -60
Hi Matt,
On Fri, Dec 28, 2018 at 03:51:30PM -0800, Matt Roper wrote:
> Some display controllers can be programmed to present non-black colors
> for pixels not covered by any plane (or pixels covered by the
> transparent regions of higher planes). Compositors that want a UI with
> a solid color ba
On Fri, Jan 04, 2019 at 03:37:09PM +, Tvrtko Ursulin wrote:
> diff --git a/tests/intel-ci/blacklist.txt b/tests/intel-ci/blacklist.txt
> index 73d127603d28..d76a4b3b1c71 100644
> --- a/tests/intel-ci/blacklist.txt
> +++ b/tests/intel-ci/blacklist.txt
> @@ -60,6 +60,7 @@ igt@gem_ring_sync_copy(@
Quoting José Roberto de Souza (2019-01-04 19:37:00)
> According to Workaround database ICL also needs
> WaEnablePreemptionGranularityControlByUMD, to allow userspace to do
> fine-granularity preemptions per-context.
I must wonder where is the userspace component that needs this, and why
it hasn't
Quoting Patchwork (2019-01-07 10:44:01)
> ### IGT changes ###
>
> Possible regressions
>
> * igt@gem_userptr_blits@readonly-unsync:
> - shard-apl: PASS -> TIMEOUT
>
> * igt@kms_draw_crc@draw-method-rgb565-mmap-wc-untiled:
> - shard-apl: PASS -> FAIL
>
Since we trust fb->size as either calculated by calc_fb_size() or the
supplied by the user, it invariably isn't page aligned. The mmap
routines and ioctls only deal in pages...
Not sure if fb->size should be page aligned, but that may break
some other drawing tests, so opt to just fix up the mmap
Op 04-01-2019 om 16:52 schreef Souza, Jose:
> On Fri, 2019-01-04 at 15:35 +0100, Maarten Lankhorst wrote:
>> Op 04-01-2019 om 14:28 schreef Souza, Jose:
>>> On Fri, 2019-01-04 at 07:53 +0100, Maarten Lankhorst wrote:
Op 03-01-2019 om 15:21 schreef José Roberto de Souza:
> intel_psr_set_deb
== Series Details ==
Series: series starting with [1/2] drm/i915: Prevent a race during
I915_GEM_MMAP ioctl with WC set
URL : https://patchwork.freedesktop.org/series/54797/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5364_full -> Patchwork_11198_full
==
On Thu, Jan 03, 2019 at 10:16:54AM +, Chris Wilson wrote:
> Quoting Maarten Lankhorst (2019-01-03 09:03:27)
> > Op 30-12-2018 om 13:28 schreef Chris Wilson:
> > > Delay the drm_modeset_acquire_init() until after we check for an
> > > allocation failure so that we can return immediately upon err
Quoting Tvrtko Ursulin (2019-01-07 10:19:44)
>
> On 05/01/2019 01:33, Lucas De Marchi wrote:
> > On Fri, Dec 21, 2018 at 12:29:41PM +, Tvrtko Ursulin wrote:
> >>
> >> On 14/12/2018 18:20, Lucas De Marchi wrote:
> >> we were setting unused entries to uncached, on Icelake they will be set to
> >
On 04/01/2019 23:47, Lucas De Marchi wrote:
On Fri, Dec 21, 2018 at 11:56:43AM +, Tvrtko Ursulin wrote:
On 14/12/2018 18:20, Lucas De Marchi wrote:
Instead of checking the gen number every time we need to know the max
number of entries, just save it into the table struct so we don't need
On 05/01/2019 01:33, Lucas De Marchi wrote:
On Fri, Dec 21, 2018 at 12:29:41PM +, Tvrtko Ursulin wrote:
On 14/12/2018 18:20, Lucas De Marchi wrote:
From: Tomasz Lis
The table has been unified across OSes to minimize virtualization overhead.
The MOCS table is now published as part of bs
On Thu, Jan 03, 2019 at 06:06:53PM +0100, Noralf Trønnes wrote:
>
>
> Den 28.12.2018 21.38, skrev Daniel Vetter:
> > On Tue, May 29, 2018 at 9:54 AM Daniel Vetter wrote:
> > >
> > > On Fri, May 25, 2018 at 02:42:02PM +0200, Noralf Trønnes wrote:
> > > >
> > > > Den 24.05.2018 11.16, skrev Dani
Hi,
We have had engine reset support in i915 for some time now. So lets call
this work engine watchdog or something, just not engine reset.
By calling it engine reset we have confused sites like Phoronix and some
our users.
Regards,
Tvrtko
On 05/01/2019 02:39, Carlos Santa wrote:
This i
Quoting Jani Nikula (2019-01-07 09:52:43)
> On Sat, 05 Jan 2019, Chris Wilson wrote:
> > CC [M] drivers/gpu/drm/i915/intel_device_info.o
> > drivers/gpu/drm/i915/intel_device_info.c:727: warning: Function parameter
> > or member 'dev_priv' not described in 'intel_device_info_runtime_init'
> >
On Sat, 05 Jan 2019, Chris Wilson wrote:
> CC [M] drivers/gpu/drm/i915/intel_device_info.o
> drivers/gpu/drm/i915/intel_device_info.c:727: warning: Function parameter or
> member 'dev_priv' not described in 'intel_device_info_runtime_init'
> drivers/gpu/drm/i915/intel_device_info.c:727: warnin
Quoting Chris Wilson (2019-01-05 03:46:52)
> CC [M] drivers/gpu/drm/i915/intel_device_info.o
> drivers/gpu/drm/i915/intel_device_info.c:727: warning: Function parameter or
> member 'dev_priv' not described in 'intel_device_info_runtime_init'
> drivers/gpu/drm/i915/intel_device_info.c:727: warni
On 07/01/2019 08:56, Joonas Lahtinen wrote:
Add err goto label and use it when VMA can't be established or changes
underneath.
Fixes: 1816f9236303 ("drm/i915: Support creation of unbound wc user mappings for
objects")
Reported-by: Adam Zabrocki
Signed-off-by: Joonas Lahtinen
Cc: # v4.0+
Cc:
== Series Details ==
Series: series starting with [1/2] drm/i915: Prevent a race during
I915_GEM_MMAP ioctl with WC set
URL : https://patchwork.freedesktop.org/series/54797/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5364 -> Patchwork_11198
On 07/01/2019 08:56, Joonas Lahtinen wrote:
Make sure the underlying VMA in the process address space is the
same as it was during vm_mmap to avoid applying WC to wrong VMA.
A more long-term solution would be to have vm_mmap_locked variant
in linux/mmap.h for when caller wants to hold mmap_sem
Quoting Joonas Lahtinen (2019-01-07 08:56:56)
> Add err goto label and use it when VMA can't be established or changes
> underneath.
>
> Fixes: 1816f9236303 ("drm/i915: Support creation of unbound wc user mappings
> for objects")
Dubious. All it changes is one branch where the error is forced to
Quoting Joonas Lahtinen (2019-01-07 08:56:55)
> Make sure the underlying VMA in the process address space is the
> same as it was during vm_mmap to avoid applying WC to wrong VMA.
>
> A more long-term solution would be to have vm_mmap_locked variant
> in linux/mmap.h for when caller wants to hold
Make sure the underlying VMA in the process address space is the
same as it was during vm_mmap to avoid applying WC to wrong VMA.
A more long-term solution would be to have vm_mmap_locked variant
in linux/mmap.h for when caller wants to hold mmap_sem for an
extended duration.
Fixes: 1816f9236303
Add err goto label and use it when VMA can't be established or changes
underneath.
Fixes: 1816f9236303 ("drm/i915: Support creation of unbound wc user mappings
for objects")
Reported-by: Adam Zabrocki
Signed-off-by: Joonas Lahtinen
Cc: # v4.0+
Cc: Akash Goel
Cc: Chris Wilson
Cc: Tvrtko Ursul
101 - 179 of 179 matches
Mail list logo
