== Series Details ==
Series: drm/i915/selftests: Exercise rc6 w/a handling
URL : https://patchwork.freedesktop.org/series/69687/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7377_full -> Patchwork_15333_full
Summary
--
Am 19.11.19 um 22:08 schrieb Daniel Vetter:
It's kinda really hard to get this wrong on a driver with both display
and dma_resv locking. But who ever knows, so better to make sure that
really all drivers nest these the same way.
For actual lock semantics the acquire context nesting doesn't matte
> -Original Message-
> From: Jani Nikula
> Sent: Friday, November 15, 2019 9:04 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Nikula, Jani ; Kulkarni, Vandita
> ; ville.syrj...@linux.intel.com
> Subject: [PATCH v2 10/10] drm/i915/dsi: add support for DSC
>
> Enable DSC for DSI, if speci
i915_request_add() consumes the passed in reference to the i915_request,
so if the selftest caller wishes to wait upon it afterwards, it needs to
take a reference for itself.
Signed-off-by: Chris Wilson
---
.../drm/i915/gem/selftests/i915_gem_context.c | 38 ++-
1 file changed, 2
On Tue, 2019-11-19 at 16:19 -0800, Matt Roper wrote:
> On Fri, Nov 15, 2019 at 04:54:01PM +0200, Stanislav Lisovskiy wrote:
> > According to BSpec 53998, we should try to
> > restrict qgv points, which can't provide
> > enough bandwidth for desired display configuration.
> >
> > Currently we are j
The major drawback of commit 7e34f4e4aad3 ("drm/i915/gen8+: Add RC6 CTX
corruption WA") is that it disables RC6 while Skylake (and friends) is
active, and we do not consider the GPU idle until all outstanding
requests have been retired and the engine switched over to the kernel
context. If userspac
The general concept was that intel_timeline.active_count was locked by
the intel_timeline.mutex. The exception was for power management, where
the engine->kernel_context->timeline could be manipulated under the
global wakeref.mutex.
This was quite solid, as we always manipulated the timeline only
Bonded request submission is designed to allow requests to execute in
parallel as laid out by the user. If the master request is already
finished before its bonded pair is submitted, the pair were not destined
to run in parallel and we lose the information about the master engine
to dictate selecti
Before checking the current i915_active state for the asynchronous work
we submitted, flush any ongoing callback. This ensures that our sampling
is robust and does not sporadically fail due to bad timing as the work
is running on another cpu.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/
In commit a79ca656b648 ("drm/i915: Push the wakeref->count deferral to
the backend"), I erroneously concluded that we last modify the engine
inside __i915_request_commit() meaning that we could enable concurrent
submission for userspace as we enqueued this request. However, this
falls into a trap w
i915_request_add() consumes the passed in reference to the i915_request,
so if the selftest caller wishes to wait upon it afterwards, it needs to
take a reference for itself.
Signed-off-by: Chris Wilson
---
.../drm/i915/gem/selftests/i915_gem_context.c | 38 ++-
1 file changed, 2
Now that we never allow the intel_wakeref callbacks to be invoked from
interrupt context, we do not need the irqsafe spinlock for the timeline.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_gt_requests.c | 9 -
drivers/gpu/drm/i915/gt/intel_r
When setting up a full GGTT, we expect the next insert to fail with
-ENOSPC. Simplify the use of ERR_PTR to not confuse either the reader or
smatch.
Reported-by: Dan Carpenter
References: f40a7b7558ef ("drm/i915: Initial selftests for exercising eviction")
Signed-off-by: Chris Wilson
---
driver
Previously, we assumed we could use mutex_trylock() within an atomic
context, falling back to a worker if contended. However, such trickery
is illegal inside interrupt context, and so we need to always use a
worker under such circumstances. As we normally are in process context,
we can typically us
'--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Stuart-Summers/drm-i915-gem-Ensure-aperture-exists-before-setting-domain-to-GTT/20191120-111351
base: git://anongit.freedesktop.org
On Tue, 2019-11-19 at 15:13 -0800, Matt Roper wrote:
> On Fri, Nov 15, 2019 at 04:54:00PM +0200, Stanislav Lisovskiy wrote:
> > Currently intel_can_enable_sagv function contains
> > a mix of workarounds for different platforms
> > some of them are not valid for gens >= 11 already,
> > so lets split
On Wed, 20 Nov 2019 at 09:33, Chris Wilson wrote:
>
> i915_request_add() consumes the passed in reference to the i915_request,
> so if the selftest caller wishes to wait upon it afterwards, it needs to
> take a reference for itself.
>
> Signed-off-by: Chris Wilson
> ---
> .../drm/i915/gem/selfte
On Wed, Nov 20, 2019 at 3:07 AM Rob Clark wrote:
>
> On Tue, Nov 19, 2019 at 1:08 PM Daniel Vetter wrote:
> >
> > For locking semantics it really doesn't matter when we grab the
> > ticket. But for lockdep validation it does: the acquire ctx is a fake
> > lockdep. Since other drivers might want t
On Tue, Nov 19, 2019 at 04:45:05PM -0800, Stuart Summers wrote:
> Platforms without display do not map the MCHBAR MMIO into the GFX
> device BAR. Skip this sequence when display is not available.
Slightly odd decision to hide this stuff in hw, but fine by me
since we need this only for display ban
On Wed, 20 Nov 2019 at 09:33, Chris Wilson wrote:
>
> When setting up a full GGTT, we expect the next insert to fail with
> -ENOSPC. Simplify the use of ERR_PTR to not confuse either the reader or
> smatch.
>
> Reported-by: Dan Carpenter
> References: f40a7b7558ef ("drm/i915: Initial selftests fo
Quoting Matthew Auld (2019-11-20 10:19:56)
> On Wed, 20 Nov 2019 at 09:33, Chris Wilson wrote:
> >
> > i915_request_add() consumes the passed in reference to the i915_request,
> > so if the selftest caller wishes to wait upon it afterwards, it needs to
> > take a reference for itself.
> >
> > Sign
i915_request_add() consumes the passed in reference to the i915_request,
so if the selftest caller wishes to wait upon it afterwards, it needs to
take a reference for itself.
Signed-off-by: Chris Wilson
Cc: Matthew Auld
---
.../drm/i915/gem/selftests/i915_gem_context.c | 39 ++-
On Tue, Nov 19, 2019 at 05:10:16PM -0800, Stuart Summers wrote:
> When display is not available, finding the memory bandwidth available
> for display is not useful. Skip this sequence here.
>
> References: HSDES 1209978255
>
> Signed-off-by: Stuart Summers
> ---
> drivers/gpu/drm/i915/display/i
On Wed, 20 Nov 2019 at 10:28, Chris Wilson wrote:
>
> i915_request_add() consumes the passed in reference to the i915_request,
> so if the selftest caller wishes to wait upon it afterwards, it needs to
> take a reference for itself.
>
> Signed-off-by: Chris Wilson
> Cc: Matthew Auld
Reviewed-by:
Also implemented algorithm for choosing DBuf slice configuration
based on active pipes, pipe ratio as stated in BSpec 12716.
Now pipe allocation still stays proportional to pipe width as before,
however within allowed DBuf slice for this particular configuration.
v2: Remove unneeded check from co
On Fri, Nov 15, 2019 at 10:21:20AM +0100, Daniel Vetter wrote:
> We're doing a great job for really simple drivers right now, but still
> a lot of boilerplate for the bigger ones.
>
> Signed-off-by: Daniel Vetter
Ping for some review/acks on this and the earlier driver patches (not
patch 1, that
On Thu, Nov 14, 2019 at 11:50:28AM +, Steven Price wrote:
> On 11/11/2019 15:42, Daniel Vetter wrote:
> > On Mon, Nov 11, 2019 at 2:11 PM Steven Price wrote:
> >>
> >> On 04/11/2019 17:37, Daniel Vetter wrote:
> >>> Full audit of everyone:
> >>>
> >>> - i915, radeon, amdgpu should be clean per
On Wed, Nov 20, 2019 at 09:34:03AM +0100, Christian König wrote:
> Am 19.11.19 um 22:08 schrieb Daniel Vetter:
> > It's kinda really hard to get this wrong on a driver with both display
> > and dma_resv locking. But who ever knows, so better to make sure that
> > really all drivers nest these the s
For locking semantics it really doesn't matter when we grab the
ticket. But for lockdep validation it does: the acquire ctx is a fake
lockdep. Since other drivers might want to do a full multi-lock dance
in their fault-handler, not just lock a single dma_resv. Therefore we
must init the acquire_ctx
Quoting Zhenyu Wang (2019-11-12 08:20:32)
>
> Hi,
>
> Here's one fix to remove PVINFO read in initial state for extra
> warning messages in debug.
Pulled now.
Regards, Joonas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.fre
Am 19.11.19 um 22:08 schrieb Daniel Vetter:
Semnatically it really doesn't matter where we grab the ticket. But
since the ticket is a fake lockdep lock, it matters for lockdep
validation purposes.
This means stuff like grabbing a ticket and then doing
copy_from/to_user isn't allowed anymore. Thi
On 19/11/2019 14:41, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-11-19 14:15:49)
On 18/11/2019 23:02, Chris Wilson wrote:
The general concept was that intel_timeline.active_count was locked by
the intel_timeline.mutex. The exception was for power management, where
the engine->kernel_cont
Quoting Tvrtko Ursulin (2019-11-20 11:39:00)
>
> On 19/11/2019 14:41, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-11-19 14:15:49)
> >>
> >> On 18/11/2019 23:02, Chris Wilson wrote:
> >>> The general concept was that intel_timeline.active_count was locked by
> >>> the intel_timeline.mutex.
On 20/11/2019 09:32, Chris Wilson wrote:
In commit a79ca656b648 ("drm/i915: Push the wakeref->count deferral to
the backend"), I erroneously concluded that we last modify the engine
inside __i915_request_commit() meaning that we could enable concurrent
submission for userspace as we enqueued thi
Quoting Tvrtko Ursulin (2019-11-20 11:58:27)
>
> On 20/11/2019 09:32, Chris Wilson wrote:
> > In commit a79ca656b648 ("drm/i915: Push the wakeref->count deferral to
> > the backend"), I erroneously concluded that we last modify the engine
> > inside __i915_request_commit() meaning that we could en
Hi Daniel,
how does i915/GEM lock dma_resv objects for CPU page faulting?
I've been wondering if a good bunch of ttm_bo_vm_reserve() wouldn't be
better placed in the common dma_resv.c file.
Regards,
Christian.
___
Intel-gfx mailing list
Intel-gfx@
Quoting Chuansheng Liu (2019-11-20 06:29:12)
> Reference:
> https://bugs.freedesktop.org/show_bug.cgi?id=112126
>
> The issue we hit is the GPU keeps very high load after running
> the subtest min-max-config-loaded.
>
> Some background of the issue:
> Currently the rps is not fully enabled yet on
On 20/11/2019 12:07, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-11-20 11:58:27)
On 20/11/2019 09:32, Chris Wilson wrote:
In commit a79ca656b648 ("drm/i915: Push the wakeref->count deferral to
the backend"), I erroneously concluded that we last modify the engine
inside __i915_request_com
Quoting Tvrtko Ursulin (2019-11-20 12:40:13)
>
> On 20/11/2019 12:07, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-11-20 11:58:27)
> >>
> >> On 20/11/2019 09:32, Chris Wilson wrote:
> >>> In commit a79ca656b648 ("drm/i915: Push the wakeref->count deferral to
> >>> the backend"), I erroneou
On 20/11/2019 09:32, Chris Wilson wrote:
Previously, we assumed we could use mutex_trylock() within an atomic
context, falling back to a worker if contended. However, such trickery
is illegal inside interrupt context, and so we need to always use a
worker under such circumstances. As we normally
Previously, we assumed we could use mutex_trylock() within an atomic
context, falling back to a worker if contended. However, such trickery
is illegal inside interrupt context, and so we need to always use a
worker under such circumstances. As we normally are in process context,
we can typically us
== Series Details ==
Series: drm/i915/selftests: Take a ref to the request we wait upon
URL : https://patchwork.freedesktop.org/series/69723/
State : failure
== Summary ==
Applying: drm/i915/selftests: Take a ref to the request we wait upon
Using index info to reconstruct a base tree...
M
On 20/11/2019 09:32, Chris Wilson wrote:
Bonded request submission is designed to allow requests to execute in
parallel as laid out by the user. If the master request is already
finished before its bonded pair is submitted, the pair were not destined
to run in parallel and we lose the informatio
Quoting Tvrtko Ursulin (2019-11-20 12:55:42)
>
> On 20/11/2019 09:32, Chris Wilson wrote:
> > Bonded request submission is designed to allow requests to execute in
> > parallel as laid out by the user. If the master request is already
> > finished before its bonded pair is submitted, the pair were
== Series Details ==
Series: drm/i915 / LPSS / mfd: Select correct PWM controller to use based on
VBT (rev2)
URL : https://patchwork.freedesktop.org/series/69686/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
f86bdecf3b17 ACPI / LPSS: Rename pwm_backlight pwm-lookup to pwm_soc
Op 14-11-2019 om 15:35 schreef Jani Nikula:
> On Mon, 11 Nov 2019, Jani Nikula wrote:
>> Hi Sean, Maarten and Maxime -
>>
>> Here's the topic branch about DSI changes as I wrote in [1]. Once you've
>> pulled this in drm-misc, I'll follow suit in i915.
> Ping.
>
> FWIW Daniel acked the approach on
On 20/11/2019 09:33, Chris Wilson wrote:
The major drawback of commit 7e34f4e4aad3 ("drm/i915/gen8+: Add RC6 CTX
corruption WA") is that it disables RC6 while Skylake (and friends) is
active, and we do not consider the GPU idle until all outstanding
requests have been retired and the engine swit
666
On 20/11/2019 12:44, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-11-20 12:40:13)
On 20/11/2019 12:07, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-11-20 11:58:27)
On 20/11/2019 09:32, Chris Wilson wrote:
In commit a79ca656b648 ("drm/i915: Push the wakeref->count deferral to
the
On 20/11/2019 12:59, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-11-20 12:55:42)
On 20/11/2019 09:32, Chris Wilson wrote:
Bonded request submission is designed to allow requests to execute in
parallel as laid out by the user. If the master request is already
finished before its bonded pa
On 20/11/2019 09:32, Chris Wilson wrote:
The general concept was that intel_timeline.active_count was locked by
the intel_timeline.mutex. The exception was for power management, where
the engine->kernel_context->timeline could be manipulated under the
global wakeref.mutex.
This was quite solid,
Quoting Tvrtko Ursulin (2019-11-20 13:18:27)
>
> On 20/11/2019 12:59, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-11-20 12:55:42)
> >>
> >> On 20/11/2019 09:32, Chris Wilson wrote:
> >>> Bonded request submission is designed to allow requests to execute in
> >>> parallel as laid out by th
Quoting Tvrtko Ursulin (2019-11-20 13:16:51)
>
> On 20/11/2019 09:33, Chris Wilson wrote:
> > The major drawback of commit 7e34f4e4aad3 ("drm/i915/gen8+: Add RC6 CTX
> > corruption WA") is that it disables RC6 while Skylake (and friends) is
> > active, and we do not consider the GPU idle until all
Since we use barriers, we need only explicitly flush those barriers to
ensure tha we can reclaim the available ggtt for ourselves. The barrier
flush was implicit inside the intel_gt_wait_for_idle() -- except because
we use i915_gem_evict from inside an active timeline during execbuf, we
could easil
== Series Details ==
Series: drm/i915 / LPSS / mfd: Select correct PWM controller to use based on
VBT (rev2)
URL : https://patchwork.freedesktop.org/series/69686/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7383 -> Patchwork_15341
===
On Wed, Nov 20, 2019 at 10:14:26AM +0800, Jason Wang wrote:
> > > I don't quite get the question here.
> > In the driver model the bus_type and foo_device are closely
> > linked.
>
> I don't get the definition of "closely linked" here. Do you think the bus
> and device implement virtual bus serie
== Series Details ==
Series: series starting with drm/i915/selftests: Take a ref to the request we
wait upon (rev2)
URL : https://patchwork.freedesktop.org/series/69724/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
66d127012d3d drm/i915/gt: Close race between engine_park and
== Series Details ==
Series: more dma-buf lockdep priming
URL : https://patchwork.freedesktop.org/series/69695/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7380_full -> Patchwork_15335_full
Summary
---
**SUCCESS**
Op 20-11-2019 om 12:30 schreef Christian König:
> Am 19.11.19 um 22:08 schrieb Daniel Vetter:
>> Semnatically it really doesn't matter where we grab the ticket. But
>> since the ticket is a fake lockdep lock, it matters for lockdep
>> validation purposes.
>>
>> This means stuff like grabbing a tick
On Wed, 20 Nov 2019, Maarten Lankhorst
wrote:
> Op 14-11-2019 om 15:35 schreef Jani Nikula:
>> On Mon, 11 Nov 2019, Jani Nikula wrote:
>>> Hi Sean, Maarten and Maxime -
>>>
>>> Here's the topic branch about DSI changes as I wrote in [1]. Once you've
>>> pulled this in drm-misc, I'll follow suit
On 20/11/2019 13:39, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-11-20 13:16:51)
On 20/11/2019 09:33, Chris Wilson wrote:
The major drawback of commit 7e34f4e4aad3 ("drm/i915/gen8+: Add RC6 CTX
corruption WA") is that it disables RC6 while Skylake (and friends) is
active, and we do not c
== Series Details ==
Series: series starting with drm/i915/selftests: Take a ref to the request we
wait upon (rev2)
URL : https://patchwork.freedesktop.org/series/69724/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7384 -> Patchwork_15342
Quoting Patchwork (2019-11-20 14:19:15)
> == Series Details ==
>
> Series: series starting with drm/i915/selftests: Take a ref to the request we
> wait upon (rev2)
> URL : https://patchwork.freedesktop.org/series/69724/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_
Quoting Tvrtko Ursulin (2019-11-20 14:16:17)
>
> On 20/11/2019 13:39, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-11-20 13:16:51)
> >>
> >> On 20/11/2019 09:33, Chris Wilson wrote:
> >>> +
> >>> + /*
> >>> + * Our goal here is to retire _idle_ timelines as soon as
On Mon, 04 Nov 2019, Rajat Jain wrote:
> Move the code that populates the ACPI device ID for devices, into
> more appripriate intel_acpi.c. This is done in preparation for more
> users of this code (in next patch).
I don't think your use of the code makes sense (I'll explain in reply to
the other
== Series Details ==
Series: drm/i915: Enable second dbuf slice for ICL and TGL (rev5)
URL : https://patchwork.freedesktop.org/series/69124/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
f62897cea199 drm/i915: Enable second dbuf slice for ICL and TGL
-:281: WARNING:SUSPECT_CODE
== Series Details ==
Series: drm/i915: Enable second dbuf slice for ICL and TGL (rev5)
URL : https://patchwork.freedesktop.org/series/69124/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: drm/i915: Enable second dbuf slice for ICL and TGL
+drivers/gpu/
On Mon, 04 Nov 2019, Rajat Jain wrote:
> Lookup and attach ACPI nodes for intel connectors. The lookup is done
> in compliance with ACPI Spec 6.3
> https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf
> (Ref: Pages 1119 - 1123).
>
> This can be useful for any connector specific
On Mon, 04 Nov 2019, Rajat Jain wrote:
> Certain laptops now come with panels that have integrated privacy
> screens on them. This patch adds support for such panels by adding
> a privacy-screen property to the intel_connector for the panel, that
> the userspace can then use to control and check t
Also implemented algorithm for choosing DBuf slice configuration
based on active pipes, pipe ratio as stated in BSpec 12716.
Now pipe allocation still stays proportional to pipe width as before,
however within allowed DBuf slice for this particular configuration.
v2: Remove unneeded check from co
On Wed, 2019-11-20 at 12:28 +0200, Ville Syrjälä wrote:
> On Tue, Nov 19, 2019 at 05:10:16PM -0800, Stuart Summers wrote:
> > When display is not available, finding the memory bandwidth
> > available
> > for display is not useful. Skip this sequence here.
> >
> > References: HSDES 1209978255
> >
On Wed, 2019-11-20 at 12:23 +0200, Ville Syrjälä wrote:
> On Tue, Nov 19, 2019 at 04:45:05PM -0800, Stuart Summers wrote:
> > Platforms without display do not map the MCHBAR MMIO into the GFX
> > device BAR. Skip this sequence when display is not available.
>
> Slightly odd decision to hide this s
On Tue, 12 Nov 2019, Rajat Jain wrote:
> On Mon, Nov 4, 2019 at 11:41 AM Rajat Jain wrote:
>>
>> Certain laptops now come with panels that have integrated privacy
>> screens on them. This patch adds support for such panels by adding
>> a privacy-screen property to the intel_connector for the pane
== Series Details ==
Series: drm/i915: Enable second dbuf slice for ICL and TGL (rev5)
URL : https://patchwork.freedesktop.org/series/69124/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7385 -> Patchwork_15343
Summary
Since retirement may be running in a worker on another CPU, it may be
skipped in the local intel_gt_wait_for_idle(). To ensure the state is
consistent for our sanity checks upon load, serialise with the remote
retirer by waiting on the timeline->mutex.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursul
Before we remove from the timeline, finish flushing the context state.
As the timeline may be peeked upon by another CPU, we don't want to
remove request from the timeline until we have finished working on it.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_request.
== Series Details ==
Series: more dma-buf lockdep priming (rev2)
URL : https://patchwork.freedesktop.org/series/69695/
State : failure
== Summary ==
Applying: drm/modeset: Prime modeset lock vs dma_resv
Applying: dma-resv: Also prime acquire ctx for lockdep
error: sha1 information is lacking o
== Series Details ==
Series: drm/i915: Mark up the calling context for intel_wakeref_put()
URL : https://patchwork.freedesktop.org/series/69738/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
792cc3c7a542 drm/i915: Mark up the calling context for intel_wakeref_put()
-:14: WARNIN
(fixing malformed intel-gfx list address in Cc:)
On Wednesday, November 20, 2019 4:36:41 PM CET Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2019-11-20 15:32:19)
> > As we've agreed that using I915_GEM_PREAD/PWRITE IOCTLs on dma-buf
> > objects doesn't make much sense, we are not going to ext
Quoting Janusz Krzysztofik (2019-11-20 15:49:33)
> (fixing malformed intel-gfx list address in Cc:)
>
> On Wednesday, November 20, 2019 4:36:41 PM CET Chris Wilson wrote:
> > Quoting Janusz Krzysztofik (2019-11-20 15:32:19)
> > > As we've agreed that using I915_GEM_PREAD/PWRITE IOCTLs on dma-buf
>
Whenever we wait on a request, make sure we actually hold a reference to
it and that it cannot be retired/freed on another CPU!
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 65 --
1 file changed, 52 insertions(+), 13 deletions(-)
diff --git a/
On Wednesday, November 20, 2019 4:53:30 PM CET Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2019-11-20 15:49:33)
> > (fixing malformed intel-gfx list address in Cc:)
> >
> > On Wednesday, November 20, 2019 4:36:41 PM CET Chris Wilson wrote:
> > > Quoting Janusz Krzysztofik (2019-11-20 15:32:1
On 20/11/2019 13:41, Chris Wilson wrote:
Since we use barriers, we need only explicitly flush those barriers to
ensure tha we can reclaim the available ggtt for ourselves. The barrier
flush was implicit inside the intel_gt_wait_for_idle() -- except because
we use i915_gem_evict from inside an ac
== Series Details ==
Series: drm/i915: Mark up the calling context for intel_wakeref_put()
URL : https://patchwork.freedesktop.org/series/69738/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7385 -> Patchwork_15345
Summary
Quoting Tvrtko Ursulin (2019-11-20 15:58:49)
>
> On 20/11/2019 13:41, Chris Wilson wrote:
> > Since we use barriers, we need only explicitly flush those barriers to
> > ensure tha we can reclaim the available ggtt for ourselves. The barrier
> > flush was implicit inside the intel_gt_wait_for_idle(
On 20/11/2019 15:21, Chris Wilson wrote:
Since retirement may be running in a worker on another CPU, it may be
skipped in the local intel_gt_wait_for_idle(). To ensure the state is
consistent for our sanity checks upon load, serialise with the remote
retirer by waiting on the timeline->mutex.
On 20/11/2019 15:21, Chris Wilson wrote:
Before we remove from the timeline, finish flushing the context state.
As the timeline may be peeked upon by another CPU, we don't want to
remove request from the timeline until we have finished working on it.
I have to ask why I'm afraid.
Regards,
Tv
Quoting Tvrtko Ursulin (2019-11-20 16:05:24)
>
> On 20/11/2019 15:21, Chris Wilson wrote:
> > Since retirement may be running in a worker on another CPU, it may be
> > skipped in the local intel_gt_wait_for_idle(). To ensure the state is
> > consistent for our sanity checks upon load, serialise wi
Quoting Tvrtko Ursulin (2019-11-20 16:07:14)
>
> On 20/11/2019 15:21, Chris Wilson wrote:
> > Before we remove from the timeline, finish flushing the context state.
> > As the timeline may be peeked upon by another CPU, we don't want to
> > remove request from the timeline until we have finished w
On 20/11/2019 16:02, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-11-20 15:58:49)
On 20/11/2019 13:41, Chris Wilson wrote:
Since we use barriers, we need only explicitly flush those barriers to
ensure tha we can reclaim the available ggtt for ourselves. The barrier
flush was implicit insi
On Tue, 19 Nov 2019, Randy Dunlap wrote:
> On 11/19/19 12:46 AM, Stephen Rothwell wrote:
>> Hi all,
>>
>> Changes since 20191118:
>
>
> on x86_64:
>
> ERROR: "pm_suspend_target_state" [drivers/gpu/drm/i915/i915.ko] undefined!
>
> # CONFIG_SUSPEND is not set
a70a9e998e8e ("drm/i915: Defer rc6 shu
On 20/11/2019 16:12, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-11-20 16:07:14)
On 20/11/2019 15:21, Chris Wilson wrote:
Before we remove from the timeline, finish flushing the context state.
As the timeline may be peeked upon by another CPU, we don't want to
remove request from the tim
From: Ville Syrjälä
Now that we've constrained the clipped source rectangle such
that it can't have negative dimensions doing the same for the
dst rectangle seems appropriate. Should at least result in
the clipped src and dst rectangles being a bit more consistent
with each other.
Cc: Benjamin G
From: Ville Syrjälä
Limit the scaled clip to only clip at most dst_w/h pixels.
This avoids the problem with clip_scaled() not being able
to return negative values. Since new_src_w/h is now properly
bounded we can remove the clamp()s.
Cc: Benjamin Gaignard
Cc: Maarten Lankhorst
Signed-off-by: V
Quoting Tvrtko Ursulin (2019-11-20 16:14:40)
>
> On 20/11/2019 16:02, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-11-20 15:58:49)
> >>
> >> On 20/11/2019 13:41, Chris Wilson wrote:
> >>> Since we use barriers, we need only explicitly flush those barriers to
> >>> ensure tha we can reclaim
== Series Details ==
Series: drm/i915/selftests: re-init the GT in live_gt_pm
URL : https://patchwork.freedesktop.org/series/69710/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7380_full -> Patchwork_15337_full
Summary
---
Implements the Wa_1604555607 and skips its verification as the FF_MODES2
register is writeonly till TGL B0.
Test-with: 20191120145712.27496-1-ramalinga...@intel.com
Michel Thierry (1):
drm/i915/tgl: Implement Wa_1604555607
Ramalingam C (2):
drm/i915: marking readability of WA registers
drm
At TGL A0 stepping, FF_MODE2 register read back is broken, hence
disabling the WA verification.
Signed-off-by: Ramalingam C
cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_wo
WA infrastructure is extended to record the WA register readability for
verification purpose.
With this, if a WA register is not readable for any reasons,
verification will be skipped for that WA.
Signed-off-by: Ramalingam C
Suggested-by: Chris Wilson
cc: Tvrtko Ursulin
---
drivers/gpu/drm/i9
From: Michel Thierry
Implement Wa_1604555607 (set the DS pairing timer to 128 cycles).
FF_MODE2 is part of the register state context, that's why it is
implemented here.
v2: Rebased on top of the WA refactoring (Oscar)
v3: Correctly add to ctx_workarounds_init (Michel)
v4:
uncore read is used
Since we use barriers, we need only explicitly flush those barriers to
ensure tha we can reclaim the available ggtt for ourselves. The barrier
flush was implicit inside the intel_gt_wait_for_idle() -- except because
we use i915_gem_evict from inside an active timeline during execbuf, we
could easil
1 - 100 of 202 matches
Mail list logo
