On Tue, Apr 21, 2020 at 09:21:45PM -0300, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> This is just an alias for HMM_PFN_ERROR, nothing cares that the error was
> because of a special page vs any other error case.
Looks good,
Reviewed-by: Christoph Hellwig
On Tue, Apr 21, 2020 at 09:21:43PM -0300, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> hmm_vma_walk->last is supposed to be updated after every write to the
> pfns, so that it can be returned by hmm_range_fault(). However, this is
> not done consistently. Fortunately nothing checks the
On Tue, Apr 21, 2020 at 09:21:42PM -0300, Jason Gunthorpe wrote:
> From: Jason Gunthorpe
>
> There is no reason for a user to select this or not directly - it should
> be selected by drivers that are going to use the feature, similar to how
> CONFIG_HMM_MIRROR works.
>
> Currently all drivers
Hi,
Here's current gvt-next. This removes left non-upstream xen support bits
which will be kept out of tree instead. And several guest context shadow
optimizations from Yan.
Thanks
--
The following changes since commit a61ac1e75105a077ec1efd6923ae3c619f862304:
drm/i915/gvt: Wean gvt off
== Series Details ==
Series: drm/i915/selftests: Try to detect rollback during batchbuffer preemption
URL : https://patchwork.freedesktop.org/series/76279/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8346_full -> Patchwork_17411_full
== Series Details ==
Series: drm/i915/selftests: Unroll the CS frequency loop
URL : https://patchwork.freedesktop.org/series/76277/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8345_full -> Patchwork_17410_full
Summary
== Series Details ==
Series: series starting with [1/3] drm/i915/gt: Prefer soft-rc6 over RPS
DOWN_TIMEOUT
URL : https://patchwork.freedesktop.org/series/76283/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8346 -> Patchwork_17412
== Series Details ==
Series: series starting with [1/3] drm/i915/gt: Prefer soft-rc6 over RPS
DOWN_TIMEOUT
URL : https://patchwork.freedesktop.org/series/76283/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
3703f8b4e6fc drm/i915/gt: Prefer soft-rc6 over RPS DOWN_TIMEOUT
For many configuration details within RC6 and RPS we are programming
intervals for the internal clocks. From gen11, these clocks are
configuration via the RPM_CONFIG and so for convenience, we would like
to convert to/from more natural units (ns).
Signed-off-by: Chris Wilson
Cc: Andi Shyti
Cc:
The RPS DOWN_TIMEOUT interrupt is signaled after a period of rc6, and
upon receipt of that interrupt we reprogram the GPU clocks down to the
next idle notch [to help convserve power during rc6]. However, on
execlists, we benefit from soft-rc6 immediately parking the GPU and
setting idle
Add tracek to the RPS events (interrupts, worker, enabling, threshold
selection, frequency setting), so that if we have to debug reticent HW
we have some traces to start from.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_rps.c | 48 ++---
1 file changed,
On Thu, Apr 02, 2020 at 04:55:06PM +0300, Ville Syrjälä wrote:
> On Wed, Apr 01, 2020 at 04:53:23PM -0700, Manasi Navare wrote:
> > On Wed, Feb 12, 2020 at 06:17:34PM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Most of the pfit functions are of the form:
> > >
> > > func()
On Tue, Apr 21, 2020 at 09:38:09AM -0700, Sultan Alsawaf wrote:
> Why hasn't this bug got any attention:
> https://gitlab.freedesktop.org/drm/intel/issues/1412
>
> That seems like a showstopper.
Indeed, pretty shocking. It's worth mentioning that the reporter of said
bug, after significant time
== Series Details ==
Series: drm/i915/selftests: Try to detect rollback during batchbuffer preemption
URL : https://patchwork.freedesktop.org/series/76279/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8346 -> Patchwork_17411
Since batch buffers dominant execution time, most preemption requests
should naturally occur during execution of a batch buffer. We wish to
verify that should a preemption occur within a batch buffer, when we
come to restart that batch buffer, it occurs at the interrupted
instruction and most
On 04/15, Maxime Ripard wrote:
> Hi!
>
> On Mon, Oct 21, 2019 at 10:00:39PM -0300, Brian Starkey wrote:
> > Add a test which makes commits using the writeback connector, and
> > checks the output buffer hash to make sure it is/isn't written as
> > appropriate.
> >
> > V6: Simon Ser
> > - Add igt
== Series Details ==
Series: series starting with [1/5] drm/i915: Make define for lrc state offset
(rev3)
URL : https://patchwork.freedesktop.org/series/76262/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8343_full -> Patchwork_17408_full
Hi
> > Hm, I see the point of this (and the dev_field below, although I'd go
> > with dev_member there for some consistency with other macros using
> > offset_of or container_of), but I'm not sure about the dev_ prefix.
> > Drivers use that sometimes for the struct device *, and usage for
> >
== Series Details ==
Series: series starting with [1/4] drm/i915: Introduce .set_link_train() vfunc
URL : https://patchwork.freedesktop.org/series/76213/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8334_full -> Patchwork_17391_full
Hi
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag
fixing commit: 983d308cb8f6 ("agp/intel: Serialise after GTT updates").
The bot has tested the following trees: v5.6.5, v5.5.18, v5.4.33, v4.19.116,
v4.14.176, v4.9.219, v4.4.219.
v5.6.5: Build
== Series Details ==
Series: drm/i915/selftests: Unroll the CS frequency loop
URL : https://patchwork.freedesktop.org/series/76277/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8345 -> Patchwork_17410
Summary
---
== Series Details ==
Series: drm/i915/selftests: Show the full scaling curve on failure (rev2)
URL : https://patchwork.freedesktop.org/series/76260/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8343_full -> Patchwork_17404_full
On Mon, 2020-04-20 at 23:06 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Split some overly long lines.
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 10 --
> 1 file changed, 8 insertions(+), 2
On Mon, 2020-04-20 at 23:06 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Relocate a binch of DDI specific code from intel_dp.c to intel_ddi.c
bunch
> by introducing a .set_idle_link_train() vfunc.
>
Reviewed-by: José Roberto de Souza
> Signed-off-by: Ville Syrjälä
> ---
>
On Mon, 2020-04-20 at 23:06 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Sort out some of the mess between intel_ddi.c intel_dp.c by
> introducing a .set_signal_levels() vfunc.
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Ville Syrjälä
> ---
>
On Mon, Apr 20, 2020 at 7:49 PM Al Viro wrote:
>
> The only source I'd been able to find speaks of >= 60 cycles
> (and possibly much more) for non-pipelined coprocessor instructions;
> the list of such does contain loads and stores to a bunch of registers.
> However, the register in
== Series Details ==
Series: RFC drm/i915/gem: Allow creation of contexts with an 'empty' VM
URL : https://patchwork.freedesktop.org/series/76276/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8345 -> Patchwork_17409
Hi Chris,
On Mon, Apr 20, 2020 at 01:53:55PM +0100, Chris Wilson wrote:
> Since moving the obj->vma.list to a spin_lock, and the vm->bound_list to
> its vm->mutex, along with tracking shrinkable status under its own
> spinlock, we no long require the object to be locked by the caller.
>
> This
== Series Details ==
Series: series starting with [01/24] perf/core: Only copy-to-user after
completely unlocking all locks, v3.
URL : https://patchwork.freedesktop.org/series/76255/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8342_full -> Patchwork_17402_full
Having noticed that MI_BB_START is incurring a memory stall (see the
correlation with uncore frequency), we have to unroll the loop in order
to diminish the impact of the MI_BB_START on the instruction throughput.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/selftest_rps.c | 32
On Tue, Apr 21, 2020 at 11:04:13AM +0300, Joonas Lahtinen wrote:
> Quoting Sultan Alsawaf (2020-04-20 18:42:16)
> > On Mon, Apr 20, 2020 at 12:02:39PM +0300, Joonas Lahtinen wrote:
> > > I think the the patch should be dropped for now before the issue is
> > > properly addressed. Either by
On Tue, Apr 21, 2020 at 09:51:37AM +0300, Joonas Lahtinen wrote:
> Quoting Sultan Alsawaf (2020-04-20 19:15:14)
> > On Mon, Apr 20, 2020 at 11:21:42AM +0300, Joonas Lahtinen wrote:
> > > So it seems that the patch got pulled into v5.6 and has been backported
> > > to v5.5 but not v5.4.
> >
> >
Quoting Chris Wilson (2020-04-21 17:41:30)
> Normally when we create a new context, and a new ppGTT to go with it, we
> point all the unused pages in the ppGTT to a 'safe' scratch page. Any
> inadvertent access outside of the declared user's area will result in a
> read/write to scratch instead.
Normally when we create a new context, and a new ppGTT to go with it, we
point all the unused pages in the ppGTT to a 'safe' scratch page. Any
inadvertent access outside of the declared user's area will result in a
read/write to scratch instead. However, sometimes it is preferrable to
that to
== Series Details ==
Series: drm/i915/gt: Prefer soft-rc6 over RPS DOWN_TIMEOUT (rev3)
URL : https://patchwork.freedesktop.org/series/76216/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8342_full -> Patchwork_17400_full
On Mon, Apr 20, 2020 at 02:14:10PM +0300, Stanislav Lisovskiy wrote:
> Future platforms require per-crtc SAGV evaluation
> and serializing global state when those are changed
> from different commits.
>
> v2: - Add has_sagv check to intel_crtc_can_enable_sagv
> so that it sets bit in reject
== Series Details ==
Series: series starting with [1/5] drm/i915: Make define for lrc state offset
(rev3)
URL : https://patchwork.freedesktop.org/series/76262/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8343 -> Patchwork_17408
== Series Details ==
Series: drm/i915/selftests: Disable C-states when measuring RPS frequency
response
URL : https://patchwork.freedesktop.org/series/76272/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8343 -> Patchwork_17407
== Series Details ==
Series: series starting with [1/5] drm/i915: Make define for lrc state offset
(rev3)
URL : https://patchwork.freedesktop.org/series/76262/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ebd226e97eaa drm/i915: Make define for lrc state offset
91d36088a541
== Series Details ==
Series: drm/i915/gt: Poison residual state [HWSP] across resume. (rev5)
URL : https://patchwork.freedesktop.org/series/76100/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8342_full -> Patchwork_17399_full
== Series Details ==
Series: series starting with [1/4] drm/i915: Introduce .set_link_train() vfunc
URL : https://patchwork.freedesktop.org/series/76213/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8334 -> Patchwork_17391
Quoting Chris Wilson (2020-04-21 14:53:54)
> Quoting Chris Wilson (2020-04-21 14:50:51)
> > Quoting Chris Wilson (2020-04-21 14:45:12)
> > > In RPS, we have the option to only specify the unslice [ring] clock
> > > ratio and for the pcu to derive the slice [gpu] clock ratio from its
> > > magic
== Series Details ==
Series: drm/i915/gt: Make the slice:unslice ratio request explicit for RPS
URL : https://patchwork.freedesktop.org/series/76269/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8343 -> Patchwork_17406
Chris Wilson writes:
> Let's isolate the impact of cpu frequency selection on determing the GPU
> throughput in response to selection of RPS frequencies.
>
> For real systems, we do have to be concerned with the impact of
> integrating c-states, p-states and rp-states, but for the sake of
>
On 21/04/2020 10:25, Chris Wilson wrote:
Since we may lose the content of any buffer when we relinquish control
of the system (e.g. suspend/resume), we have to be careful not to rely
on regaining control. A good method to detect when we might be using
garbage is by always injecting that
Use indirect ctx bb to load cmd buffer control value
from context image to avoid corruption.
v2: add to lrc layout (Chris)
v3: end to a cacheline (Chris)
Testcase: igt/i915_selftest/gt_lrc
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 73 +++--
We use different workarounds for render engine than
for other engines. Split the selftest according to these
types so that we get error rates per workaround.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 23 ---
1 file changed, 20 insertions(+), 3
Let's isolate the impact of cpu frequency selection on determing the GPU
throughput in response to selection of RPS frequencies.
For real systems, we do have to be concerned with the impact of
integrating c-states, p-states and rp-states, but for the sake of
proving whether or not RPS works, one
== Series Details ==
Series: series starting with [1/5] drm/i915: Make define for lrc state offset
URL : https://patchwork.freedesktop.org/series/76262/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8343 -> Patchwork_17405
Quoting Mika Kuoppala (2020-04-21 14:56:46)
> Chris Wilson writes:
>
> > Quoting Chris Wilson (2020-04-21 14:45:12)
> >> In RPS, we have the option to only specify the unslice [ring] clock
> >> ratio and for the pcu to derive the slice [gpu] clock ratio from its
> >> magic table. We also have
Quoting Mika Kuoppala (2020-04-21 15:00:08)
> Chris Wilson writes:
>
> > If we detect that the RPS end points do not scale perfectly, take the
> > time to measure all the in between values as well. We are aborting the
> > test, so we might as well spend the available time gathering critical
> >
Hi
Am 21.04.20 um 15:41 schrieb Daniel Vetter:
> On Tue, Apr 21, 2020 at 2:46 PM Thomas Zimmermann wrote:
>>
>> Hi Dave, Daniel,
>>
>> just a friendly reminder to merge these changes. They don't seem to be
>> in the upstream tree yet.
>
> Dave noticed and pinged me on irc that there's some
Hi
Am 21.04.20 um 12:45 schrieb Daniel Vetter:
> On Mon, Apr 20, 2020 at 3:37 PM Thomas Zimmermann wrote:
>>
>> Hi
>>
>> Am 15.04.20 um 09:39 schrieb Daniel Vetter:
>>> Add a new macro helper to combine the usual init sequence in drivers,
>>> consisting of a kzalloc + devm_drm_dev_init +
Chris Wilson writes:
> If we detect that the RPS end points do not scale perfectly, take the
> time to measure all the in between values as well. We are aborting the
> test, so we might as well spend the available time gathering critical
> debug information instead.
>
> Signed-off-by: Chris
Chris Wilson writes:
> Quoting Chris Wilson (2020-04-21 14:45:12)
>> In RPS, we have the option to only specify the unslice [ring] clock
>> ratio and for the pcu to derive the slice [gpu] clock ratio from its
>> magic table. We also have the option to tell the pcu to use our
>> requested gpu
== Series Details ==
Series: series starting with [1/5] drm/i915: Make define for lrc state offset
URL : https://patchwork.freedesktop.org/series/76262/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
52efd944a36d drm/i915: Make define for lrc state offset
c968fc0ee7cf drm/i915:
Quoting Chris Wilson (2020-04-21 14:50:51)
> Quoting Chris Wilson (2020-04-21 14:45:12)
> > In RPS, we have the option to only specify the unslice [ring] clock
> > ratio and for the pcu to derive the slice [gpu] clock ratio from its
> > magic table. We also have the option to tell the pcu to use
== Series Details ==
Series: drm/i915/selftests: Show the full scaling curve on failure (rev2)
URL : https://patchwork.freedesktop.org/series/76260/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8343 -> Patchwork_17404
Quoting Chris Wilson (2020-04-21 14:45:12)
> In RPS, we have the option to only specify the unslice [ring] clock
> ratio and for the pcu to derive the slice [gpu] clock ratio from its
> magic table. We also have the option to tell the pcu to use our
> requested gpu clock ratio, and for it to try
Chris Wilson writes:
> Quoting Mika Kuoppala (2020-04-21 14:16:33)
>> @@ -4774,6 +4773,12 @@ static int live_lrc_timestamp(void *arg)
>> unsigned long heartbeat;
>> int i, err = 0;
>>
>> + if (rcs && data.engine->class != RENDER_CLASS)
>> +
In RPS, we have the option to only specify the unslice [ring] clock
ratio and for the pcu to derive the slice [gpu] clock ratio from its
magic table. We also have the option to tell the pcu to use our
requested gpu clock ratio, and for it to try and throttle the unslice
and slice ratios
On Tue, Apr 21, 2020 at 2:46 PM Thomas Zimmermann wrote:
>
> Hi Dave, Daniel,
>
> just a friendly reminder to merge these changes. They don't seem to be
> in the upstream tree yet.
Dave noticed and pinged me on irc that there's some changes in core mm
in this one. That patch is correctly acked
Quoting Mika Kuoppala (2020-04-21 14:16:33)
> @@ -4774,6 +4773,12 @@ static int live_lrc_timestamp(void *arg)
> unsigned long heartbeat;
> int i, err = 0;
>
> + if (rcs && data.engine->class != RENDER_CLASS)
> + continue;
> +
>
Quoting Mika Kuoppala (2020-04-21 14:16:32)
> - END(80)
> + END(185)
Round up to the next cacheline(192) for safety paranoia.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
Mika Kuoppala writes:
> Indirect ctx batchbuffers are a hw feature of which
> batch can be run, by hardware, during context restoration stage.
> Driver can setup a batchbuffer and also an offset into the
> context image. When context image is marshalled from
> memory to registers, and when the
Restoration of a previous timestamp can collide
with updating the timestamp, causing a value corruption.
Combat this issue by using indirect ctx bb to
modify the context image during restoring process.
For render engine, we can preload value into
scratch register. From which we then do the
We use different workarounds for render engine than
for other engines. Split the selftest according to these
types so that we get error rates per workaround.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 26 +++---
1 file changed, 23
Indirect ctx batchbuffers are a hw feature of which
batch can be run, by hardware, during context restoration stage.
Driver can setup a batchbuffer and also an offset into the
context image. When context image is marshalled from
memory to registers, and when the offset from the start of
context
Use indirect ctx bb to load cmd buffer control value
from context image to avoid corruption.
v2: add to lrc layout (Chris)
Testcase: igt/i915_selftest/gt_lrc
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 73 +++--
More often than not, we need a byte offset into lrc
register state from the start of the hw state. Make it so.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_context_sseu.c | 3 +--
drivers/gpu/drm/i915/gt/intel_lrc.c | 8
drivers/gpu/drm/i915/gt/intel_lrc.h
On 15/04/2020 10:40, Daniel Vetter wrote:
Not used anymore since the switch to suspend/resume helpers.
Tested-by: Jyri Sarha
Acked-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
Cc: Jyri Sarha
Cc: Tomi Valkeinen
---
drivers/gpu/drm/tidss/tidss_drv.h | 2 --
1 file changed, 2 deletions(-)
If we detect that the RPS end points do not scale perfectly, take the
time to measure all the in between values as well. We are aborting the
test, so we might as well spend the available time gathering critical
debug information instead.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
Hi Dave, Daniel,
just a friendly reminder to merge these changes. They don't seem to be
in the upstream tree yet.
Best regards
Thomas
Am 14.04.20 um 11:07 schrieb Thomas Zimmermann:
> Hi Dave, Daniel,
>
> with 5.7-rc1 being tagged, here's the first PR for drm-next-misc for what
> will become
If we detect that the RPS end points do not scale perfectly, take the
time to measure all the in between values as well. We are aborting the
test, so we might as well spend the available time gathering critical
debug information instead.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
== Series Details ==
Series: series starting with [01/24] perf/core: Only copy-to-user after
completely unlocking all locks, v3.
URL : https://patchwork.freedesktop.org/series/76255/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8342 -> Patchwork_17402
== Series Details ==
Series: Sync i915_pciids upto 8717c6b7414f (rev5)
URL : https://patchwork.freedesktop.org/series/76080/
State : failure
== Summary ==
Applying: Sync i915_pciids upto 8717c6b7414f
error: sha1 information is lacking or useless (src/intel_module.c).
error: could not build
== Series Details ==
Series: series starting with [01/24] perf/core: Only copy-to-user after
completely unlocking all locks, v3.
URL : https://patchwork.freedesktop.org/series/76255/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
8184ca928432 perf/core: Only copy-to-user after
Quoting Patchwork (2020-04-21 12:37:30)
> ### IGT changes ###
>
> Possible regressions
>
> * igt@i915_selftest@live@gt_timelines:
> - fi-snb-2520m: [PASS][1] -> [FAIL][2]
>[1]:
>
== Series Details ==
Series: drm/i915/gt: Apply a small scalefactor for the gpu:ring ratio
URL : https://patchwork.freedesktop.org/series/76254/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8342 -> Patchwork_17401
Summary
Quoting Liwei Song (2020-04-21 11:19:55)
> Import the kernel's i915_pciids.h, up to:
>
> commit 8717c6b7414ffb890672276dccc284c23078ac0e
> Author: Lee Shawn C
> Date: Tue Dec 10 23:04:15 2019 +0800
>
> drm/i915/cml: Separate U series pci id from origianl list.
>
> Signed-off-by: Liwei
On 15/04/2020 10:39, Daniel Vetter wrote:
Already using devm_drm_dev_init, so very simple replacment.
Tested-by: Jyri Sarha
Acked-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
Cc: Jyri Sarha
Cc: Tomi Valkeinen
---
drivers/gpu/drm/tidss/tidss_drv.c | 15 ---
1 file changed, 4
On 15/04/2020 10:39, Daniel Vetter wrote:
Upcasting using a container_of macro is more typesafe, faster and
easier for the compiler to optimize.
Tested-by: Jyri Sarha
Acked-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
Cc: Jyri Sarha
Cc: Tomi Valkeinen
---
Import the kernel's i915_pciids.h, up to:
commit 8717c6b7414ffb890672276dccc284c23078ac0e
Author: Lee Shawn C
Date: Tue Dec 10 23:04:15 2019 +0800
drm/i915/cml: Separate U series pci id from origianl list.
Signed-off-by: Liwei Song
---
V4 -> V5:
adjust gen number
V3 -> V4:
Add
== Series Details ==
Series: drm/i915/gt: Prefer soft-rc6 over RPS DOWN_TIMEOUT (rev3)
URL : https://patchwork.freedesktop.org/series/76216/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8342 -> Patchwork_17400
Summary
We want to start using ww locking in intel_context_pin, for this
we need to lock multiple objects, and the single i915_gem_object_lock
is not enough.
Convert to using ww-waiting, and make sure we always pin intel_context_state,
even if we don't have a renderstate object.
Signed-off-by: Maarten
We want to introduce backoff logic, but we need to lock the
pool object as well for command parsing. Because of this, we
will need backoff logic for the engine pool obj, move the batch
validation up slightly to eb_lookup_vmas, and the actual command
parsing in a separate function which can get
i915_gem_ww_ctx is used to lock all gem bo's for pinning and memory
eviction. We don't use it yet, but lets start adding the definition
first.
To use it, we have to pass a non-NULL ww to gem_object_lock, and don't
unlock directly. It is done in i915_gem_ww_ctx_fini.
Changes since v1:
- Change
This reverts commit 0f1dd02295f35dcdcbaafcbcbbec0753884ab974.
This conflicts with the ww mutex handling, which needs to drop
the references after gpu submission anyway, because otherwise we
may risk unlocking a BO after first freeing it.
Signed-off-by: Maarten Lankhorst
---
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 51 +++-
1 file changed, 33 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index b39c24dae64e..e35e8d0b6938
This function does not use intel_context_create_request, so it has
to use the same locking order as normal code. This is required to
shut up lockdep in selftests.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 15 ---
1 file changed, 12 insertions(+),
We want to lock all gem objects, including the engine context objects,
rework the throttling to ensure that we can do this. Now we only throttle
once, but can take eb_pin_engine while acquiring objects. This means we
will have to drop the lock to wait. If we don't have to throttle we can
still
Instead of using intel_context_create_request(), use intel_context_pin()
and i915_create_request directly.
Now all those calls are gone outside of selftests. :)
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 43 ++---
1 file changed, 29
We have the ordering of timeline->mutex vs resv_lock wrong,
convert the i915_pin_vma and intel_context_pin as well to
future-proof this.
We may need to do future changes to do this more transaction-like,
and only get down to a single i915_gem_ww_ctx, but for now this
should work.
Signed-off-by:
Make sure vma_lock is not used as inner lock when kernel context is used,
and add ww handling where appropriate.
Signed-off-by: Maarten Lankhorst
---
.../i915/gem/selftests/i915_gem_coherency.c | 26 ++--
.../drm/i915/gem/selftests/i915_gem_mman.c| 41 ++-
From: Chris Wilson
Since the introduction of 'soft-rc6', we aim to park the device quickly
and that results in frequent idling of the whole device. Currently upon
idling we free the batch buffer pool, and so this renders the cache
ineffective for many workloads. If we want to have an effective
Now that we changed execbuf submission slightly to allow us to do all
pinning in one place, we can now simply add ww versions on top of
struct_mutex. All we have to do is a separate path for -EDEADLK
handling, which needs to unpin all gem bo's before dropping the lock,
then starting over.
This
We inadvertently create a dependency on mmap_sem with a whole chain.
This breaks any user who wants to take a lock and call rcu_barrier(),
while also taking that lock inside mmap_sem:
<4> [604.892532] ==
<4> [604.892534] WARNING: possible
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 65 --
drivers/gpu/drm/i915/gem/i915_gem_object.h | 1 +
2 files changed, 49 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
This is the last part outside of selftests that still don't use the
correct lock ordering of timeline->mutex vs resv_lock.
With gem fixed, there are a few places that still get locking wrong:
- gvt/scheduler.c
- i915_perf.c
- Most if not all selftests.
Changes since v1:
- Add
Instead of doing everything inside of pin_mutex, we move all pinning
outside. Because i915_active has its own reference counting and
pinning is also having the same issues vs mutexes, we make sure
everything is pinned first, so the pinning in i915_active only needs
to bump refcounts. This allows
1 - 100 of 153 matches
Mail list logo
