On Tue, Jun 23, 2020 at 6:54 AM Dave Airlie wrote:
>
> On Mon, 22 Jun 2020 at 19:55, Jani Nikula wrote:
> >
> > On Mon, 22 Jun 2020, Daniel Vetter wrote:
> > > On Wed, Jun 17, 2020 at 05:42:15PM -0700, Lucas De Marchi wrote:
> > >> From: Abdiel Janulgue
> > >>
> > >> Bspec: 33617, 33617
> > >>
On Tue, Jun 16, 2020 at 10:16:29PM +, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [1/6] drm/i915/tgl+: Use the correct DP_TP_*
> register instances in MST encoders
> URL : https://patchwork.freedesktop.org/series/78423/
> State : success
Patches 1-5 pushed to
Hi Zhenyu, and Zhiyuan
Thanks a lot for your comments. and glad to know it is in the TODO list.
We really need this feature to make our released image workable on both GVT-g
and GVT-d/native.
Multiple plane/overlay are important to us for meeting the Graphics performance
target.
Do you have an
On Tue, Jun 23, 2020 at 10:29:57AM +0530, Ayaz A Siddiqui wrote:
In order to avoid functional breakage of mis-programmed applications that
have grown to depend on unused MOCS entries, we are programming
those entries to be equal to fully cached ("L3 + LLC") entry.
These reserved and unspecified
== Series Details ==
Series: drm/i915/gt: Initialize reserved and unspecified MOCS indices (rev2)
URL : https://patchwork.freedesktop.org/series/78012/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8654_full -> Patchwork_18008_full
== Series Details ==
Series: drm/i915/dp_mst: Enable VC payload allocation after transcoder is
enabled
URL : https://patchwork.freedesktop.org/series/78728/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
c95fdf71011e drm/i915/dp_mst: Enable VC payload allocation after
Quoting Thomas Hellström (Intel) (2020-06-23 10:33:20)
> Hi, Chris!
>
> On 6/22/20 11:59 AM, Chris Wilson wrote:
> > In order to actually handle eviction and what not, we need to process
> > all the objects together under a common lock, reservation_ww_class. As
> > such, do a memory reservation
On 6/23/20 1:22 PM, Thomas Hellström (Intel) wrote:
Hi, Chris,
On 6/22/20 11:59 AM, Chris Wilson wrote:
In order to actually handle eviction and what not, we need to process
all the objects together under a common lock, reservation_ww_class. As
such, do a memory reservation pass after looking
On Mon, Jun 22, 2020 at 04:28:20PM -0700, Lucas De Marchi wrote:
> We don't need intel_dig_port and dig_port to refer to the same thing.
> Prefer the latter.
>
> Signed-off-by: Lucas De Marchi
> Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 7 +++
> 1 file
Re-reported.
-Original Message-
From: Imre Deak
Sent: Tuesday, June 23, 2020 2:53 PM
To: intel-gfx@lists.freedesktop.org; Vudum, Lakshminarayana
Subject: Re: ✗ Fi.CI.IGT: failure for drm/i915/dp_mst: Enable VC payload
allocation after transcoder is enabled
Hi Lakshmi,
On Tue, Jun
Hi Lakshmi,
On Tue, Jun 23, 2020 at 11:11:46AM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/dp_mst: Enable VC payload allocation after transcoder is
> enabled
> URL : https://patchwork.freedesktop.org/series/78728/
> State : failure
>
> == Summary ==
>
> CI Bug Log -
On Fri, Jun 19, 2020 at 01:14:04PM -0700, Rodrigo Vivi wrote:
> On Fri, Jun 19, 2020 at 10:09:00AM +0200, Greg KH wrote:
> > On Thu, Jun 18, 2020 at 01:27:00PM -0700, Rodrigo Vivi wrote:
> > > From: Swathi Dhanavanthri
> > >
> > > commit 63d0f3ea8ebb67160eca281320d255c72b0cb51a upstream.
> > >
== Series Details ==
Series: drm/i915/dp_mst: Enable VC payload allocation after transcoder is
enabled
URL : https://patchwork.freedesktop.org/series/78728/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8655_full -> Patchwork_18009_full
Quoting Thomas Hellström (Intel) (2020-06-23 13:57:06)
>
> On 6/23/20 1:22 PM, Thomas Hellström (Intel) wrote:
> > Hi, Chris,
> >
> > On 6/22/20 11:59 AM, Chris Wilson wrote:
> >> In order to actually handle eviction and what not, we need to process
> >> all the objects together under a common
== Series Details ==
Series: drm/i915/dp_mst: Enable VC payload allocation after transcoder is
enabled
URL : https://patchwork.freedesktop.org/series/78728/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8655 -> Patchwork_18009
== Series Details ==
Series: VRR capable attach prop in i915, VRR debugfs (rev2)
URL : https://patchwork.freedesktop.org/series/78670/
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: VRR capable attach prop in i915, VRR debugfs (rev2)
URL : https://patchwork.freedesktop.org/series/78670/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
2ee51bf6e884 drm/i915/dp: Attach and set drm connector VRR property
377c60b4f795 drm/debug:
Hi, Chris,
On 6/22/20 11:59 AM, Chris Wilson wrote:
In order to actually handle eviction and what not, we need to process
all the objects together under a common lock, reservation_ww_class. As
such, do a memory reservation pass after looking up the object/vma,
which then feeds into the rest of
On Fri, Jun 12, 2020 at 1:35 AM Felix Kuehling wrote:
>
> Am 2020-06-11 um 10:15 a.m. schrieb Jason Gunthorpe:
> > On Thu, Jun 11, 2020 at 10:34:30AM +0200, Daniel Vetter wrote:
> >>> I still have my doubts about allowing fence waiting from within shrinkers.
> >>> IMO ideally they should use a
The spec requires enabling the MST Virtual Channel payload allocation
- in a seperate step - after the transcoder is enabled, follow this.
Cc: Ville Syrjälä
Cc: José Roberto de Souza
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_ddi.c| 8 +++-
Hi, Chris!
On 6/22/20 11:59 AM, Chris Wilson wrote:
In order to actually handle eviction and what not, we need to process
all the objects together under a common lock, reservation_ww_class. As
such, do a memory reservation pass after looking up the object/vma,
which then feeds into the rest of
== Series Details ==
Series: drm/i915/dp_mst: Enable VC payload allocation after transcoder is
enabled
URL : https://patchwork.freedesktop.org/series/78728/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8655_full -> Patchwork_18009_full
On Wed, Jun 17, 2020 at 12:11:46AM +0300, Imre Deak wrote:
> Atm, we clear the ACT sent flag in the sink's DPCD before updating the
> sink's payload table, along clearing the payload table updated flag.
> The sink is supposed to set this flag once it detects that the source
> has completed the ACT
== Series Details ==
Series: VRR capable attach prop in i915, VRR debugfs (rev2)
URL : https://patchwork.freedesktop.org/series/78670/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8655 -> Patchwork_18010
Summary
---
Hi Roland & vmwgfx maintainers,
Thomas has played around with these annotations on his vmwgfx setup,
and found some issues. Apparently in the atomic_commit_tail path when
handling the dirty rectangle stuff you acquire a ttm reservation,
which is a no-go since it could deadlock with other paths -
On Mon, Jun 22, 2020 at 06:31:24PM +0300, Jani Nikula wrote:
> On Tue, 16 Jun 2020, ramadevi.ga...@intel.com wrote:
> > From: Gandi Ramadevi
> >
> > Add DG1 PCI ID
>
> There are no DG1 PCI IDs in kernel. So please don't add them here
> either.
Also, do we have anything left using libdrm-intel?
On 6/23/20 4:01 PM, Chris Wilson wrote:
Quoting Thomas Hellström (Intel) (2020-06-23 13:57:06)
On 6/23/20 1:22 PM, Thomas Hellström (Intel) wrote:
Hi, Chris,
On 6/22/20 11:59 AM, Chris Wilson wrote:
In order to actually handle eviction and what not, we need to process
all the objects
On 6/23/20 6:17 PM, Chris Wilson wrote:
Quoting Thomas Hellström (Intel) (2020-06-23 16:09:08)
You can't take the dma_resv_lock inside a fence critical section.
I much prefer the alternative interpretation, you can't wait inside a
dma_resv_lock.
-Chris
I respect your point of view, athough
Quoting Thomas Hellström (Intel) (2020-06-23 16:37:30)
>
> On 6/23/20 12:03 PM, Chris Wilson wrote:
> > Quoting Thomas Hellström (Intel) (2020-06-23 10:33:20)
> >> Hi, Chris!
> >>
> >> On 6/22/20 11:59 AM, Chris Wilson wrote:
> >>> In order to actually handle eviction and what not, we need to
== Series Details ==
Series: drm/i915: Add support for HDCP 1.4 over MST
URL : https://patchwork.freedesktop.org/series/78749/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
40a9cf573823 drm/i915: Fix sha_text population code
-:69: WARNING:LINE_SPACING: Missing a blank line
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 964a9b0f611ee ("drm/i915/gem: Use chained reloc batches")
and commit 0e97fbb080553 ("drm/i915/gem: Use a single chained reloc batches
for a single execbuf").
This breaks ww mutex -EDEADLK handling, and we can deal with relocations
fine without it. The ww mutexes protect
Quoting Maarten Lankhorst (2020-06-23 15:28:18)
> This reverts commit 9e0f9464e2ab36b864359a59b0e9058fdef0ce47,
> and related commit 7ac2d2536dfa7 ("drm/i915/gem: Delete unused code").
Regardless that you haven't adapted the series...
This still prevents concurrent submission between clients,
Hi, Daniel:
Daniel Vetter 於 2020年6月13日 週六 上午12:01寫道：
>
> Now also comes with the added benefit of doing a drm_crtc_vblank_off(),
> which means vblank state isn't ill-defined and fail-y at driver load
> before the first modeset on each crtc.
>
Acked-by: Chun-Kuang Hu
> Signed-off-by: Daniel
== Series Details ==
Series: drm/fb-helper: Fix vt restore
URL : https://patchwork.freedesktop.org/series/78746/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
71234d269281 drm/fb-helper: Fix vt restore
-:33: WARNING:TYPO_SPELLING: 'wheter' may be misspelled - perhaps
Quoting Thomas Hellström (Intel) (2020-06-23 12:22:11)
> Hi, Chris,
>
> On 6/22/20 11:59 AM, Chris Wilson wrote:
> > In order to actually handle eviction and what not, we need to process
> > all the objects together under a common lock, reservation_ww_class. As
> > such, do a memory reservation
Some i915 selftests still use i915_vma_lock() as inner lock, and
intel_context_create_request() intel_timeline->mutex as outer lock.
Fortunately for selftests this is not an issue, they should be fixed
but we can move ahead and cleanify lockdep now.
Signed-off-by: Maarten Lankhorst
---
Make sure vma_lock is not used as inner lock when kernel context is used,
and add ww handling where appropriate.
Ensure that execbuf selftests keep passing by using ww handling.
Signed-off-by: Maarten Lankhorst
---
.../i915/gem/selftests/i915_gem_coherency.c | 26 ++--
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.
[mlankhorst: Adjusted for reloc_gpu_flush() changes]
Cc: Chris Wilson
Cc: Matthew
This reverts commit 9e0f9464e2ab36b864359a59b0e9058fdef0ce47,
and related commit 7ac2d2536dfa7 ("drm/i915/gem: Delete unused code").
Breaks the execbuf ww locking series.
Signed-off-by: Maarten Lankhorst
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 314 --
As a preparation step for full object locking and wait/wound handling
during pin and object mapping, ensure that we always pass the ww context
in i915_gem_execbuffer.c to i915_vma_pin, use lockdep to ensure this
happens.
This also requires changing the order of eb_parse slightly, to ensure
we
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
In the past we had a pile of hacks to orchestrate access between fbdev
emulation and native kms clients. We've tried to streamline this, by
always preferring the kms side above fbdev calls when a drm master
exists, because drm master controls access to the display resources.
Unfortunately this
== Series Details ==
Series: series starting with [01/26] Revert "drm/i915/gem: Async GPU
relocations only"
URL : https://patchwork.freedesktop.org/series/78744/
State : failure
== Summary ==
Applying: Revert "drm/i915/gem: Async GPU relocations only"
Applying: drm/i915: Revert relocation
On 6/23/20 12:03 PM, Chris Wilson wrote:
Quoting Thomas Hellström (Intel) (2020-06-23 10:33:20)
Hi, Chris!
On 6/22/20 11:59 AM, Chris Wilson wrote:
In order to actually handle eviction and what not, we need to process
all the objects together under a common lock, reservation_ww_class. As
Quoting Thomas Hellström (Intel) (2020-06-23 16:09:08)
>
> On 6/23/20 4:01 PM, Chris Wilson wrote:
> > Quoting Thomas Hellström (Intel) (2020-06-23 13:57:06)
> >> On 6/23/20 1:22 PM, Thomas Hellström (Intel) wrote:
> >>> Hi, Chris,
> >>>
> >>> On 6/22/20 11:59 AM, Chris Wilson wrote:
> In
From: Sean Paul
Instead of using intel_dig_port's encoder pipe to determine which
transcoder to toggle signalling on, use the cpu_transcoder field already
stored in intel_hdmi.
This is particularly important for MST.
Suggested-by: Ville Syrjälä
Reviewed-by: Ramalingam C
Signed-off-by: Sean
From: Sean Paul
Currently we derive the connector from digital port in check_link(). For
MST, this isn't sufficient since the digital port passed into the
function can have multiple connectors downstream. This patch adds
connector to the check_link() arguments so we have it when we need it.
Quoting Thomas Hellström (Intel) (2020-06-23 16:09:08)
> You can't take the dma_resv_lock inside a fence critical section.
I much prefer the alternative interpretation, you can't wait inside a
dma_resv_lock.
-Chris
___
Intel-gfx mailing list
== Series Details ==
Series: drm/fb-helper: Fix vt restore
URL : https://patchwork.freedesktop.org/series/78746/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8658 -> Patchwork_18012
Summary
---
**SUCCESS**
No
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
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.c | 22 +++-
2 files changed, 48
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
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
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 fe27c5b344e3..874fa0489f6d
The lock here should be interruptible, so we can backoff if needed.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
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(+),
Killing context before taking ctx->mutex fixes a hang in
gem_ctx_persistence.close-replace-race, where lut_close
takes obj->resv.lock which is already held by execbuf,
causing a stalling indefinitely.
[ 1904.342847] 2 locks held by gem_ctx_persist/11520:
[ 1904.342849] #0: 8882188e4968
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
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/gt/intel_renderstate.c | 2 +-
drivers/gpu/drm/i915/i915_vma.c | 9 -
drivers/gpu/drm/i915/i915_vma.h | 3 +++
3 files changed, 12 insertions(+), 2 deletions(-)
diff --git
Execbuffer submission will perform its own WW locking, and we
cannot rely on the implicit lock there.
This also makes it clear that the GVT code will get a lockdep splat when
multiple batchbuffer shadows need to be performed in the same instance,
fix that up.
Signed-off-by: Maarten Lankhorst
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:
We want to get rid of intel_context_pin(), convert
intel_context_create_request() first. :)
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_context.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git
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
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
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 17 +++--
1 file changed, 7
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
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
From: Sean Paul
These functions are all the same for dp and dp_mst, so move them into a
dedicated file for both sst and mst to use.
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-11-s...@poorly.run
#v1
Link:
From: Sean Paul
This patch plumbs port through hdcp init instead of relying on
intel_attached_encoder() to return a non-NULL encoder which won't work
for MST connectors.
Cc: Ville Syrjälä
Signed-off-by: Sean Paul
Link:
From: Sean Paul
HDCP signalling should not be left on, WARN if it is
Cc: Ville Syrjälä
Cc: Daniel Vetter
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-4-s...@poorly.run
#v2
Link:
From: Sean Paul
Add an out label and un-indent hdcp disable in preparation for
hdcp_mutex. No functional changes
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-9-s...@poorly.run
#v6
Changes in v7:
-Split into separate patch (Ramalingam)
---
From: Sean Paul
Now that all the groundwork has been laid, we can turn on HDCP 1.4 over
MST. Everything except for toggling the HDCP signalling and HDCP 2.2
support is the same as the DP case, so we'll re-use those callbacks
Cc: Juston Li
Signed-off-by: Sean Paul
Link:
From: Sean Paul
Used to query whether an MST stream is encrypted or not.
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-14-s...@poorly.run
#v4
Link:
https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-15-s...@poorly.run
From: Sean Paul
This patch adds some protection against connectors being destroyed
before the HDCP workers are finished.
For check_work, we do a synchronous cancel after the connector is
unregistered which will ensure that it is finished before destruction.
In the case of prop_work, we can't
From: Sean Paul
This patch is required for HDCP over MST. If a port is being used for
multiple HDCP streams, we don't want to fully disable HDCP on a port if
one of them is disabled. Instead, we just disable the HDCP signalling on
that particular pipe and exit early. The last pipe to disable
From: Sean Paul
In order to act upon content_protection property changes, we'll need to
implement the .update_pipe() hook. We can re-use intel_ddi_update_pipe
for this
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-10-s...@poorly.run
#v1
From: Sean Paul
On HDCP disable, clear the repeater bit. This ensures if we connect a
non-repeater sink after a repeater, the bit is in the state we expect.
Fixes: ee5e5e7a5e0f (drm/i915: Add HDCP framework + base implementation)
Cc: Chris Wilson
Cc: Ramalingam C
Cc: Daniel Vetter
Cc: Sean
From: Sean Paul
Although DP_MST fake encoders are not subclassed from digital ports,
they are associated with them. Support these encoders.
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-9-s...@poorly.run
#v1
Link:
From: Sean Paul
De-duplicate the HDCP version code for each connector and print it for
all connectors.
Cc: Juston Li
Cc: Ramalingam C
Reviewed-by: Juston Li
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
From: Sean Paul
This is a bit of housecleaning for a future patch. Instead of sprinkling
hdcp->value assignments and prop_work scheduling everywhere, introduce a
function to do it for us.
Reviewed-by: Ramalingam C
Signed-off-by: Sean Paul
Link:
From: Sean Paul
Instead of hand rolling the transfer ourselves in the hdcp hook, inspect
aux messages and add the aksv flag in the aux transfer hook.
IIRC, this was the original implementation and folks wanted this hack to
be isolated to the hdcp code, which makes sense.
However in testing an
From: Sean Paul
No functional changes, this set has the following changes since v6:
- rebased on drm-tip
- split "drm/i915: Clean up intel_hdcp_disable" out of "drm/i915: Don't
fully disable HDCP on a port if multiple pipes are using it"
- remove hdcp2 dpmst stubs
Regarding "level of testing"
From: Sean Paul
This patch fixes a few bugs:
1- We weren't taking into account sha_leftovers when adding multiple
ksvs to sha_text. As such, we were or'ing the end of ksv[j - 1] with
the beginning of ksv[j]
2- In the sha_leftovers == 2 and sha_leftovers == 3 case, bstatus was
being
== Series Details ==
Series: drm/i915: Add support for HDCP 1.4 over MST
URL : https://patchwork.freedesktop.org/series/78749/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.
-
Quoting Thomas Hellström (Intel) (2020-06-23 17:29:46)
>
> On 6/23/20 6:17 PM, Chris Wilson wrote:
> > Quoting Thomas Hellström (Intel) (2020-06-23 16:09:08)
> >> You can't take the dma_resv_lock inside a fence critical section.
> > I much prefer the alternative interpretation, you can't wait
== Series Details ==
Series: drm/i915: Add support for HDCP 1.4 over MST
URL : https://patchwork.freedesktop.org/series/78749/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8658 -> Patchwork_18013
Summary
---
On Sun, Jun 21, 2020 at 10:01:03PM +0200, Daniel Vetter wrote:
> On Sun, Jun 21, 2020 at 08:07:08PM +0200, Daniel Vetter wrote:
> > On Sun, Jun 21, 2020 at 7:42 PM Qian Cai wrote:
> > >
> > > On Wed, Jun 10, 2020 at 09:41:01PM +0200, Daniel Vetter wrote:
> > > > fs_reclaim_acquire/release nicely
On Tue, Jun 23, 2020 at 05:16:06PM +0300, Ville Syrjälä wrote:
On Mon, Jun 22, 2020 at 04:28:20PM -0700, Lucas De Marchi wrote:
We don't need intel_dig_port and dig_port to refer to the same thing.
Prefer the latter.
Signed-off-by: Lucas De Marchi
Reviewed-by: Matt Roper
---
On Tue, 2020-06-23 at 11:24 +0300, Imre Deak wrote:
> The spec requires enabling the MST Virtual Channel payload allocation
> - in a seperate step - after the transcoder is enabled, follow this.
>
Is the next step but indeed a different step.
Reviewed-by: José Roberto de Souza
> Cc: Ville
On 6/23/20 6:36 PM, Chris Wilson wrote:
Quoting Thomas Hellström (Intel) (2020-06-23 12:22:11)
Hi, Chris,
On 6/22/20 11:59 AM, Chris Wilson wrote:
In order to actually handle eviction and what not, we need to process
all the objects together under a common lock, reservation_ww_class. As
On Tue, Jun 23, 2020 at 02:44:24PM -0400, Felix Kuehling wrote:
> Am 2020-06-23 um 3:39 a.m. schrieb Daniel Vetter:
> > On Fri, Jun 12, 2020 at 1:35 AM Felix Kuehling
> > wrote:
> >> Am 2020-06-11 um 10:15 a.m. schrieb Jason Gunthorpe:
> >>> On Thu, Jun 11, 2020 at 10:34:30AM +0200, Daniel
Quoting Thomas Hellström (Intel) (2020-06-23 19:21:28)
>
> On 6/23/20 6:36 PM, Chris Wilson wrote:
> > Quoting Thomas Hellström (Intel) (2020-06-23 12:22:11)
> >> Hi, Chris,
> >>
> >> On 6/22/20 11:59 AM, Chris Wilson wrote:
> >>> In order to actually handle eviction and what not, we need to
Am 2020-06-23 um 3:39 a.m. schrieb Daniel Vetter:
> On Fri, Jun 12, 2020 at 1:35 AM Felix Kuehling wrote:
>> Am 2020-06-11 um 10:15 a.m. schrieb Jason Gunthorpe:
>>> On Thu, Jun 11, 2020 at 10:34:30AM +0200, Daniel Vetter wrote:
> I still have my doubts about allowing fence waiting from
On Tue, 2020-06-23 at 16:03 -0700, Lucas De Marchi wrote:
> On Tue, Jun 23, 2020 at 3:58 PM José Roberto de Souza
> wrote:
> > This is new step that was recently added to the combo phy
> > initialization.
> >
> > BSpec: 49291
> > Signed-off-by: José Roberto de Souza
> > ---
> >
On Wed, 2020-06-17 at 17:42 -0700, Lucas De Marchi wrote:
> From: Matt Roper
>
> RKL uses a slightly different bit layout for the DPCLKA_CFGCR0 register.
>
> v2:
> - Fix inverted mask application when updating ICL_DPCLKA_CFGCR0
> - Checkpatch style fixes
>
Reviewed-by: José Roberto de Souza
On Wed, 2020-06-17 at 17:42 -0700, Lucas De Marchi wrote:
> From: Matt Roper
>
> If HTI (also sometimes called HDPORT) is enabled at startup, it may be
> using some of the PHYs and DPLLs making them unavailable for general
> usage. Let's read out the HDPORT_STATE register and avoid making use
On Wed, 2020-06-17 at 17:42 -0700, Lucas De Marchi wrote:
> From: Matt Roper
>
> After doing normal PHY-B initialization on Rocket Lake, we need to
> manually copy some additional PHY-A register values into PHY-B
> registers.
Damn, just sent this, did a search using 14011471926 and did not
On 6/23/20 11:15 PM, Chris Wilson wrote:
Quoting Thomas Hellström (Intel) (2020-06-23 21:31:38)
On 6/23/20 8:41 PM, Chris Wilson wrote:
Quoting Thomas Hellström (Intel) (2020-06-23 19:21:28)
On 6/23/20 6:36 PM, Chris Wilson wrote:
Quoting Thomas Hellström (Intel) (2020-06-23 12:22:11)
Hi,
On Wed, 24 Jun 2020 at 11:36, Stephen Rothwell wrote:
>
> Hi all,
>
> On Wed, 17 Jun 2020 10:59:29 +1000 Stephen Rothwell
> wrote:
> >
> > After merging the drm-misc tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> >
1 - 100 of 123 matches
Mail list logo
