On 2020.08.11 10:25:32 +0100, Chris Wilson wrote:
> The "mmio" writes into vgpu registers are simple memory traps from the
> guest into the host. We do not need to assert in the guest that the
> device is awake for the io as we do not write to the device itself.
>
> However, over time we have refa
On Wed, 12 Aug 2020 at 06:06, Lyude Paul wrote:
>
> This is another bit that we never implemented for nouveau: dongle
> detection. When a "dongle", e.g. an active display adaptor, is hooked up
> to the system and causes an HPD to be fired, we don't actually know
> whether or not there's anything p
On Wed, 12 Aug 2020 at 06:07, Lyude Paul wrote:
>
> Now that we've extracted i915's code for reading both the normal DPCD
> caps and extended DPCD caps into a shared helper, let's start using this
> in nouveau to enable us to start checking extended DPCD caps for free.
>
> Signed-off-by: Lyude Pau
On Wed, 12 Aug 2020 at 06:06, Lyude Paul wrote:
>
> Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
> ---
> drivers/gpu/drm/nouveau/nouveau_dp.c | 16 +++-
> 1 file changed, 3 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
> b/drivers/gpu/dr
On Wed, 12 Aug 2020 at 06:05, Lyude Paul wrote:
>
> Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
> ---
> drivers/gpu/drm/nouveau/nouveau_dp.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
> b/drivers/gpu/drm/nouveau/
== Series Details ==
Series: drm/dp, i915, nouveau: Cleanup nouveau HPD and add DP features from
i915 (rev3)
URL : https://patchwork.freedesktop.org/series/80542/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8872 -> Patchwork_18348
===
== Series Details ==
Series: drm/dp, i915, nouveau: Cleanup nouveau HPD and add DP features from
i915 (rev3)
URL : https://patchwork.freedesktop.org/series/80542/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be check
== Series Details ==
Series: drm/dp, i915, nouveau: Cleanup nouveau HPD and add DP features from
i915 (rev3)
URL : https://patchwork.freedesktop.org/series/80542/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
5adc3389c2b0 drm/nouveau/kms: Fix some indenting in nouveau_dp_detec
Ah-nevermind, Ickle pointed out to me that it just takes a little bit for the
results to migrate over to AWS, things seem to be viewable now.
On Tue, 2020-08-11 at 18:17 -0400, Lyude Paul wrote:
> Can someone take a look at this? All of the CI related links here just give
> a permission denied when
Can someone take a look at this? All of the CI related links here just give a
permission denied when you try to view them, and I'm positive this test
failure has nothing to do with this series
On Tue, 2020-08-11 at 22:13 +, Patchwork wrote:
>
> Patch Details
>
> Series:drm/dp, i915, nouveau:
== Series Details ==
Series: drm/dp, i915, nouveau: Cleanup nouveau HPD and add DP features from
i915 (rev2)
URL : https://patchwork.freedesktop.org/series/80542/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8872 -> Patchwork_18347
===
== Series Details ==
Series: drm/dp, i915, nouveau: Cleanup nouveau HPD and add DP features from
i915 (rev2)
URL : https://patchwork.freedesktop.org/series/80542/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be check
== Series Details ==
Series: drm/dp, i915, nouveau: Cleanup nouveau HPD and add DP features from
i915 (rev2)
URL : https://patchwork.freedesktop.org/series/80542/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
7429fbed7536 drm/nouveau/kms: Fix some indenting in nouveau_dp_detec
== Series Details ==
Series: drm/dp, i915, nouveau: Cleanup nouveau HPD and add DP features from i915
URL : https://patchwork.freedesktop.org/series/80542/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8872 -> Patchwork_18346
===
== Series Details ==
Series: drm/dp, i915, nouveau: Cleanup nouveau HPD and add DP features from i915
URL : https://patchwork.freedesktop.org/series/80542/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separ
== Series Details ==
Series: drm/dp, i915, nouveau: Cleanup nouveau HPD and add DP features from i915
URL : https://patchwork.freedesktop.org/series/80542/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d04a1583d0fe drm/nouveau/kms: Fix some indenting in nouveau_dp_detect()
-:7:
== Series Details ==
Series: series starting with [v6,01/11] HAX to make DSC work on the icelake
test system (rev4)
URL : https://patchwork.freedesktop.org/series/79534/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8871_full -> Patchwork_18345_full
==
Currently in nouveau_connector_ddc_detect() and
nouveau_connector_detect_lvds(), we start the connector probing process
by releasing the previous EDID and informing DRM of the change. However,
since commit 5186421cbfe2 ("drm: Introduce epoch counter to
drm_connector") drm_connector_update_edid_prop
While the way we find the associated connector for an encoder is just
fine for legacy modesetting, it's not correct for nv50+ since that uses
atomic modesetting. For reference, see the drm_encoder kdocs.
Fix this by removing nouveau_encoder_connector_get(), and replacing it
with nv04_encoder_get_c
To start off: this patch series is less work to review then it looks -
most (but not all) of the nouveau related work has already been reviewed
elsewhere. Most of the reason I'm asking for an RFC here is because this
code pulls a lot of code out of i915 and into shared DP helpers.
Anyway-nouveau's
We're going to be doing the same probing process in nouveau for
determining downstream DP port capabilities, so let's deduplicate the
work by moving i915's code for handling this into a shared helper:
drm_dp_downstream_read_info().
Note that when we do this, we also do make some functional changes
This is another bit that we never implemented for nouveau: dongle
detection. When a "dongle", e.g. an active display adaptor, is hooked up
to the system and causes an HPD to be fired, we don't actually know
whether or not there's anything plugged into the dongle without checking
the sink count. As
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index 8a0f7994e1aeb..ee778ddc95fae 100644
--- a/drivers/gpu/drm/nouveau/nouve
Since other drivers are also going to need to be aware of the sink count
in order to do proper dongle detection, we might as well steal i915's
DP_SINK_COUNT helpers and move them into DRM helpers so that other
dirvers can use them as well.
Note that this also starts using intel_dp_has_sink_count()
And of course, we'll also need to read the sink count from other drivers
as well if we're checking whether or not it's supported. So, let's
extract the code for this into another helper.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_helper.c | 20
drivers/gpu/
Since DP 1.3, it's been possible for DP receivers to specify an
additional set of DPCD capabilities, which can take precedence over the
capabilities reported at DP_DPCD_REV.
Basically any device supporting DP is going to need to read these in an
identical manner, in particular nouveau, so let's go
Now that we've extracted i915's code for reading both the normal DPCD
caps and extended DPCD caps into a shared helper, let's start using this
in nouveau to enable us to start checking extended DPCD caps for free.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 14 ++
Currently we perform both short IRQ handling for DP, and connector
reprobing in the HPD IRQ handler. However since we need to grab
connection_mutex in order to reprobe a connector, in theory we could
accidentally block ourselves from handling any short IRQs until after a
modeset completes if a conn
Just a tiny drive-by cleanup, we can consolidate i915's code for
checking for MST support into a helper to be shared across drivers.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/i915/display/intel_dp.c | 18 ++
include/drm/drm_dp_mst_helper.h | 22 ++
Just use drm_dp_dpcd_(readb|writeb)() so we get automatic DPCD logging
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers
This adds support for querying the maximum clock rate of a downstream
port on a DisplayPort connection. Generally, downstream ports refer to
active dongles which can have their own pixel clock limits.
Note as well, we also start marking the connector as disconnected if we
can't read the DPCD, sinc
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 16 +++-
1 file changed, 3 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index d701f09aea645..bb85d81c25244 100644
--- a/drivers/gpu/drm/nou
Since this actually logs accesses, we should probably always be using
this imho…
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/dr
Noticed this while going through our DP code - we use an open-coded
version of drm_dp_read_desc() instead of just using the helper, so
change that. This will also let us use quirks in the future if we end up
needing them.
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nou
First some backstory here: Currently, we keep track of whether or not
we've enabled MST or not by trying to piggy-back off the MST helpers.
This means that in order to check whether MST is enabled or not, we
actually need to grab drm_dp_mst_topology_mgr.lock.
Back when I originally wrote this, I d
No functional changes.
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index 8db9216d52c69..4030806
Since fa3cdf8d0b09 ("drm/nouveau: Reset MST branching unit before
enabling") we've been clearing DP_MST_CTRL before we start enabling MST.
Since then clearing DP_MST_CTRL in nv50_mstm_new() has been unnecessary
and redundant, so let's remove it.
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
For whatever reason we currently unset the EDID for DP CEC support when
responding to the connector being unplugged, instead of just doing it in
nouveau_connector_detect() where we set the CEC EDID. This isn't really
needed and could even potentially cause us to forget to unset the EDID
if the conn
From: kernel test robot
drivers/gpu/drm/i915/gt/gen6_ppgtt.c:263:6-8: ERROR: iterator variable bound on
line 262 cannot be NULL
drivers/gpu/drm/i915/gt/gen6_ppgtt.c:322:7-9: ERROR: iterator variable bound on
line 321 cannot be NULL
Many iterators have the property that the first argument is a
tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
head: 06b108297b5cc24418e91c1103587ac7ca6fd03f
commit: 1d567ec619333e54283dcd02780ab9a71ef86e44 [27/28] drm/i915/gt: Switch to
object allocations for page directories
config: i386-randconfig-c001-20200811 (attached as .config
== Series Details ==
Series: series starting with [v6,01/11] HAX to make DSC work on the icelake
test system (rev4)
URL : https://patchwork.freedesktop.org/series/79534/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8871 -> Patchwork_18345
== Series Details ==
Series: series starting with [v6,01/11] HAX to make DSC work on the icelake
test system (rev4)
URL : https://patchwork.freedesktop.org/series/79534/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't b
== Series Details ==
Series: series starting with [v6,01/11] HAX to make DSC work on the icelake
test system (rev4)
URL : https://patchwork.freedesktop.org/series/79534/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
292437cfd978 HAX to make DSC work on the icelake test system
On Thu, Jul 9, 2020 at 8:40 AM Anshuman Gupta wrote:
>
\snip
> > > +static int
> > > +intel_dp_mst_hdcp_toggle_signalling(struct intel_digital_port
> > > *intel_dig_port,
> > > + enum transcoder cpu_transcoder,
> > > + bool enable)
> >
On Thu, Jul 9, 2020 at 9:09 AM Anshuman Gupta wrote:
>
> On 2020-07-02 at 20:07:36 +0530, Anshuman Gupta wrote:
> > On 2020-06-30 at 12:48:34 -0400, Sean Paul wrote:
> > > On Tue, Jun 30, 2020 at 10:21 AM Anshuman Gupta
> > > wrote:
> > > >
> > > > On 2020-06-23 at 21:29:05 +0530, Sean Paul wrote
On Tue, 2020-08-11 at 01:49 +, Patchwork wrote:
> Patch Details
> Series: series starting with [CI,1/2] drm/i915: Initial implementation
> of PSR2 selective fetch (rev2)
> URL: https://patchwork.freedesktop.org/series/80478/
> State:success
> Details:
> https://intel-gfx-c
On Tue, Aug 11, 2020 at 04:57:48AM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/kbl: Fix revision ID checks (rev2)
> URL : https://patchwork.freedesktop.org/series/80419/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_8867_full -> Patchwork_1833
== Series Details ==
Series: drm/i915/kbl: Fix revision ID checks (rev3)
URL : https://patchwork.freedesktop.org/series/80419/
State : failure
== Summary ==
Applying: drm/i915/kbl: Fix revision ID checks
error: corrupt patch at line 56
error: could not build fake ancestor
hint: Use 'git am --s
Reviewed-by: Swathi Dhanavanthri
-Original Message-
From: Intel-gfx On Behalf Of Matt
Roper
Sent: Monday, August 10, 2020 8:21 PM
To: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH v2] drm/i915/kbl: Fix revision ID checks
We usually assume that increasing PCI device revisi
Quoting Lionel Landwerlin (2020-08-11 16:37:10)
> On 11/08/2020 12:17, Chris Wilson wrote:
> > We assume that both timestamps are driven off the same clock [reported
> > to userspace as I915_PARAM_CS_TIMESTAMP_FREQUENCY]. Verify that this is
> > so by reading the timestamp registers around a busywa
On 11/08/2020 12:17, Chris Wilson wrote:
We assume that both timestamps are driven off the same clock [reported
to userspace as I915_PARAM_CS_TIMESTAMP_FREQUENCY]. Verify that this is
so by reading the timestamp registers around a busywait (on an otherwise
idle engine so there should be no preemp
On Mon, Aug 10, 2020 at 12:30:43PM +0200, Maarten Lankhorst wrote:
> This reverts commit 0f1dd02295f35dcdcbaafcbcbbec0753884ab974.
Needs some help with dim cite.
> With the WW locking, we will drop all references only at the
> end, so refcounting can be removed.
>
> Signed-off-by: Maarten Lankho
On Thu, Jul 2, 2020 at 10:49 AM Anshuman Gupta wrote:
>
> On 2020-06-30 at 12:48:34 -0400, Sean Paul wrote:
> > On Tue, Jun 30, 2020 at 10:21 AM Anshuman Gupta
> > wrote:
> > >
\snip
> > > > +static bool
> > > > +drm_dp_sideband_parse_query_stream_enc_status(
> > > > +
On Mon, Aug 10, 2020 at 12:30:42PM +0200, Maarten Lankhorst wrote:
> This reverts commit 7dc8f1143778 ("drm/i915/gem: Drop relocation
> slowpath"). We need the slowpath relocation for taking ww-mutex
> inside the page fault handler, and we will take this mutex when
> pinning all objects.
>
> With
== Series Details ==
Series: drm/i915/gt:fix raw-wakeref not held calltrace in vGPU (rev2)
URL : https://patchwork.freedesktop.org/series/80497/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8868_full -> Patchwork_18343_full
== Series Details ==
Series: drm/i915/selftests: Confirm RING_TIMESTAMP / CTX_TIMESTAMP share a
clock (rev2)
URL : https://patchwork.freedesktop.org/series/80475/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8868_full -> Patchwork_18342_full
=
On Mon, Aug 10, 2020 at 12:30:41PM +0200, Maarten Lankhorst wrote:
> This reverts commit 964a9b0f611ee ("drm/i915/gem: Use chained reloc batches")
> and commit 0e97fbb080553 ("drm/i915/gem: Use a single chained reloc batches
> for a single execbuf").
>
> When adding ww locking to execbuf, it's har
On Mon, Aug 10, 2020 at 12:30:40PM +0200, Maarten Lankhorst wrote:
> This reverts commit 9e0f9464e2ab36b864359a59b0e9058fdef0ce47,
Missed one, you need to dim cite the above so the commit subject is
included. Also too long sha1.
-Daniel
> and related commit 7ac2d2536dfa7 ("drm/i915/gem: Delete un
Op 11-08-2020 om 09:34 schreef Thomas Hellström (Intel):
>
> On 8/10/20 12:30 PM, Maarten Lankhorst wrote:
>> As soon as we install fences, we should stop allocating memory
>> in order to prevent any potential deadlocks.
>>
>> This is required later on, when we start adding support for
>> dma-fence
== Series Details ==
Series: i915/gem: Force HW tracking to exit PSR (rev2)
URL : https://patchwork.freedesktop.org/series/80391/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8868_full -> Patchwork_18341_full
Summary
-
== Series Details ==
Series: drm/i915/gt:fix raw-wakeref not held calltrace in vGPU (rev2)
URL : https://patchwork.freedesktop.org/series/80497/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8868 -> Patchwork_18343
Summary
On Tue, 11 Aug 2020 at 04:23, Dave Airlie wrote:
>
> Hi Matthew,
>
> do you have a rebase of these or a git tree with them, once I hit the
> PPGTT support applying started to get messy.
Yeah, that stuff pretty much needed a rewrite.
https://github.com/matt-auld/linux/tree/drm-tip-lmem-dg1
__
== Series Details ==
Series: drm/i915/gt:fix raw-wakeref not held calltrace in vGPU (rev2)
URL : https://patchwork.freedesktop.org/series/80497/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ecbbc5815c0f drm/i915: Drop runtime-pm assert from vgpu io accessors
-:16: WARNING:COMM
== Series Details ==
Series: drm/i915/selftests: Confirm RING_TIMESTAMP / CTX_TIMESTAMP share a
clock (rev2)
URL : https://patchwork.freedesktop.org/series/80475/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8868 -> Patchwork_18342
===
== Series Details ==
Series: drm/i915/selftests: Confirm RING_TIMESTAMP / CTX_TIMESTAMP share a
clock (rev2)
URL : https://patchwork.freedesktop.org/series/80475/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
6f2c2821cb2d drm/i915/selftests: Confirm RING_TIMESTAMP / CTX_TIMEST
== Series Details ==
Series: i915/gem: Force HW tracking to exit PSR (rev2)
URL : https://patchwork.freedesktop.org/series/80391/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8868 -> Patchwork_18341
Summary
---
**SU
On Mon, Aug 10, 2020 at 12:30:40PM +0200, Maarten Lankhorst wrote:
> This reverts commit 9e0f9464e2ab36b864359a59b0e9058fdef0ce47,
> and related commit 7ac2d2536dfa7 ("drm/i915/gem: Delete unused code").
>
> Async GPU relocations are not the path forward, we want to remove
> GPU accelerated reloca
The "mmio" writes into vgpu registers are simple memory traps from the
guest into the host. We do not need to assert in the guest that the
device is awake for the io as we do not write to the device itself.
However, over time we have refactored all the mmio accessors with the
result that the vgpu
We assume that both timestamps are driven off the same clock [reported
to userspace as I915_PARAM_CS_TIMESTAMP_FREQUENCY]. Verify that this is
so by reading the timestamp registers around a busywait (on an otherwise
idle engine so there should be no preemptions).
v2: Icelake (not ehl, nor tgl) see
== Series Details ==
Series: i915/gem: Force HW tracking to exit PSR (rev2)
URL : https://patchwork.freedesktop.org/series/80391/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.
_
== Series Details ==
Series: i915/gem: Force HW tracking to exit PSR (rev2)
URL : https://patchwork.freedesktop.org/series/80391/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
f25572dd467f i915/gem: Force HW tracking to exit PSR
-:44: CHECK:PARENTHESIS_ALIGNMENT: Alignment shou
On 2020.08.11 09:26:11 +0100, Chris Wilson wrote:
> Quoting Yan Zhao (2020-08-11 04:02:09)
> > UNCORE_HAS_FORCEWAKE is not turned on when intel_vgpu_active() returns
> > true, so the guest mmio writes go to gen2_write32().
>
> The vgpu writes are just memory traps, the device wakeref should not be
Instead of calling i915_gem_object_invalidate_frontbuffer(),
call i915_gem_object_flush_frontbuffer() which will eventually
call psr_force_hw_tracking_exit(). This will force HW tracking
to exit PSR instead of disabling and re-enabling.
On Gen9 Intel chromebooks, while playing around with Squid so
On Tue, Aug 11, 2020 at 09:26:11AM +0100, Chris Wilson wrote:
> Quoting Yan Zhao (2020-08-11 04:02:09)
> > UNCORE_HAS_FORCEWAKE is not turned on when intel_vgpu_active() returns
> > true, so the guest mmio writes go to gen2_write32().
>
> The vgpu writes are just memory traps, the device wakeref s
Quoting Yan Zhao (2020-08-11 04:02:09)
> UNCORE_HAS_FORCEWAKE is not turned on when intel_vgpu_active() returns
> true, so the guest mmio writes go to gen2_write32().
The vgpu writes are just memory traps, the device wakeref should not be
required. It seems like we've accidentally added the assert
On 8/10/20 12:30 PM, Maarten Lankhorst wrote:
Those arguments are already set as eb.file and eb.args, so kill off
the extra arguments. This will allow us to move eb_pin_engine() to
after we reserved all BO's.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Tvrtko Ursulin
Reviewed-by: Thomas H
Quoting Maarten Lankhorst (2020-08-10 11:30:39)
> First start with a few reverts, to get to a good starting base for this
> series:
> - Async gpu relocations are not the way to go, for new platforms we will
> disable gpu relocations altogether.
> - We also need the relocation slowpath (EFAULT han
On 8/10/20 12:30 PM, Maarten Lankhorst wrote:
This is required if we want to pass a ww context in intel_context_pin
and gen6_ppgtt_pin().
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 55 ++-
.../drm/i915/gem/selftests/i915_gem_context.
On 8/10/20 12:30 PM, Maarten Lankhorst wrote:
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
On 8/10/20 12:30 PM, Maarten Lankhorst wrote:
As soon as we install fences, we should stop allocating memory
in order to prevent any potential deadlocks.
This is required later on, when we start adding support for
dma-fence annotations, and also required for userptr.
Signed-off-by: Maarten La
80 matches
Mail list logo
