== Series Details ==
Series: Parallel submission aka multi-bb execbuf (rev5)
URL : https://patchwork.freedesktop.org/series/92789/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10681 -> Patchwork_21241
Summary
---
== Series Details ==
Series: series starting with [v5,01/13] drm/ttm: stop calling tt_swapin in
vm_access (rev2)
URL : https://patchwork.freedesktop.org/series/95093/
State : failure
== Summary ==
Applying: drm/ttm: stop calling tt_swapin in vm_access
Using index info to reconstruct a base
Hi Matthew/Thomas,
See one question inline
Regards,
Oak
-Original Message-
From: Intel-gfx On Behalf Of Matthew
Auld
Sent: September 27, 2021 7:41 AM
To: intel-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org; Thomas Hellström
; Christian König
Subject: [Intel-gfx]
== Series Details ==
Series: Parallel submission aka multi-bb execbuf (rev5)
URL : https://patchwork.freedesktop.org/series/92789/
State : warning
== Summary ==
$ make htmldocs 2>&1 > /dev/null | grep i915
./drivers/gpu/drm/i915/gt/uc/intel_guc.h:166: warning: Function parameter or
member
== Series Details ==
Series: Parallel submission aka multi-bb execbuf (rev5)
URL : https://patchwork.freedesktop.org/series/92789/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: Parallel submission aka multi-bb execbuf (rev5)
URL : https://patchwork.freedesktop.org/series/92789/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
fc9c9fb6630a drm/i915/guc: Move GuC guc_id allocation under submission state
sub-struct
Hi all, could you please share your comments for the latest patch? Thanks!
Best regards,
Shawn
>
>Gmbus driver would setup all Intel i2c GMBuses. But DDC bus may configured as
>gpio and reserved for MIPI driver to control panel power on/off sequence.
>
>Using i2c tool to communicate to
On 2021-10-01 08:11, Sean Paul wrote:
From: Sean Paul
This patch updates the connector's property value in 2 cases which were
previously missed:
1- Content type changes. The value should revert back to DESIRED from
ENABLED in case the driver must re-authenticate the link due to the
new
== Series Details ==
Series: drm/i915: Improve DP link training further (rev3)
URL : https://patchwork.freedesktop.org/series/95405/
State : failure
== Summary ==
Applying: drm/i915: Tweak the DP "max vswing reached?" condition
Applying: drm/i915: Show LTTPR in the TPS debug print
Applying:
== Series Details ==
Series: Parallel submission aka multi-bb execbuf (rev4)
URL : https://patchwork.freedesktop.org/series/92789/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10681 -> Patchwork_21239
Summary
---
== Series Details ==
Series: Parallel submission aka multi-bb execbuf (rev4)
URL : https://patchwork.freedesktop.org/series/92789/
State : warning
== Summary ==
$ make htmldocs 2>&1 > /dev/null | grep i915
./drivers/gpu/drm/i915/gt/uc/intel_guc.h:166: warning: Function parameter or
member
== Series Details ==
Series: Parallel submission aka multi-bb execbuf (rev4)
URL : https://patchwork.freedesktop.org/series/92789/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: Parallel submission aka multi-bb execbuf (rev4)
URL : https://patchwork.freedesktop.org/series/92789/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e2a47a99bf9d drm/i915/guc: Move GuC guc_id allocation under submission state
sub-struct
If an error occurs in the front end when multi-lrc requests are getting
generated we need to skip these in the backend but we still need to
emit the breadcrumbs seqno. An issues arises because with multi-lrc
breadcrumbs there is a handshake between the parent and children to make
forward progress.
Enable multi-bb execbuf by enabling the set_parallel extension.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index
A weak implementation of parallel submission (multi-bb execbuf IOCTL) for
execlists. Doing as little as possible to support this interface for
execlists - basically just passing submit fences between each request
generated and virtual engines are not allowed. This is on par with what
is there for
For some users of multi-lrc, e.g. split frame, it isn't safe to preempt
mid BB. To safely enable preemption at the BB boundary, a handshake
between to parent and child is needed. This is implemented via custom
emit_bb_start & emit_fini_breadcrumb functions and enabled via by
default if a context
Add very basic (single submission) multi-lrc selftest.
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 1 +
.../drm/i915/gt/uc/selftest_guc_multi_lrc.c | 179 ++
.../drm/i915/selftests/i915_live_selftests.h | 1
Display the workqueue status in debugfs for GuC contexts that are in
parent-child relationship.
v2:
(John Harrison)
- Output number children in debugfs
Signed-off-by: Matthew Brost
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 53 ++-
1 file changed, 39 insertions(+),
Introduce 'set parallel submit' extension to connect UAPI to GuC
multi-lrc interface. Kernel doc in new uAPI should explain it all.
IGT: https://patchwork.freedesktop.org/patch/447008/?series=93071=1
media UMD: https://github.com/intel/media-driver/pull/1252
v2:
(Daniel Vetter)
- Add IGT link
Allow multiple batch buffers to be submitted in a single execbuf IOCTL
after a context has been configured with the 'set_parallel' extension.
The number batches is implicit based on the contexts configuration.
This is implemented with a series of loops. First a loop is used to find
all the
Update parallel submit doc to point to i915_drm.h
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
Documentation/gpu/rfc/i915_parallel_execbuf.h | 122 --
Documentation/gpu/rfc/i915_scheduler.rst | 4 +-
2 files changed, 2 insertions(+), 124 deletions(-)
If an object in the excl or shared slot is a composite fence from a
parallel submit and the current request in the conflict tracking is from
the same parallel context there is no need to enforce ordering as the
ordering already implicit. Make the request conflict tracking understand
this by
Parallel submission create composite fences (dma_fence_array) for excl /
shared slots in objects. The I915_GEM_BUSY IOCTL checks these slots to
determine the busyness of the object. Prior to patch it only check if
the fence in the slot was a i915_request. Update the check to understand
composite
Calling switch_to_kernel_context isn't needed if the engine PM reference
is taken while all user contexts are pinned as if don't have PM ref that
guarantees that all user contexts scheduling is disabled. By not calling
switch_to_kernel_context we save on issuing a request to the engine.
v2:
Move guc_id allocation under submission state sub-struct as a future
patch will reuse the spin lock as a global submission state lock. Moving
this into sub-struct makes ownership of fields / lock clear.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context_types.h | 6 +-
Update context and full GPU reset to work with multi-lrc. The idea is
parent context tracks all the active requests inflight for itself and
its' children. The parent context owns the reset replaying / canceling
requests as needed.
v2:
(John Harrison)
- Simply loop in find active request
-
Taking a PM reference to prevent intel_gt_wait_for_idle from short
circuiting while a deregister context H2G is in flight. To do this must
issue the deregister H2G from a worker as context can be destroyed from
an atomic context and taking GT PM ref blows up. Previously we took a
runtime PM from
Expose logical engine instance to user via query engine info IOCTL. This
is required for split-frame workloads as these needs to be placed on
engines in a logically contiguous order. The logical mapping can change
based on fusing. Rather than having user have knowledge of the fusing we
simply just
The GuC must receive requests in the order submitted for contexts in a
parent-child relationship to function correctly. To ensure this, insert
a submit fence between the current request and last request submitted
for requests / contexts in a parent child relationship. This is
conceptually similar
Set number of engines before attempting to create contexts so the
function free_engines can clean up properly. Also check return of
alloc_engines for NULL.
v2:
(Tvrtko)
- Send as stand alone patch
(John Harrison)
- Check for alloc_engines returning NULL
v3:
(Checkpatch / Tvrtko)
- Remove
Implement multi-lrc submission via a single workqueue entry and single
H2G. The workqueue entry contains an updated tail value for each
request, of all the contexts in the multi-lrc submission, and updates
these values simultaneously. As such, the tasklet and bypass path have
been updated to
Assign contexts in parent-child relationship consecutive guc_ids. This
is accomplished by partitioning guc_id space between ones that need to
be consecutive (1/16 available guc_ids) and ones that do not (15/16 of
available guc_ids). The consecutive search is implemented via the bitmap
API.
This
In GuC parent-child contexts the parent context controls the scheduling,
ensure only the parent does the scheduling operations.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git
Parallel contexts are perma-pinned by the upper layers which makes the
backend implementation rather simple. The parent pins the guc_id and
children increment the parent's pin count on pin to ensure all the
contexts are unpinned before we disable scheduling with the GuC / or
deregister the
Taking a PM reference to prevent intel_gt_wait_for_idle from short
circuiting while a scheduling of user context could be enabled.
Returning GT idle when it is not can cause all sorts of issues
throughout the stack.
v2:
(Daniel Vetter)
- Add might_lock annotations to pin / unpin function
v3:
Add multi-lrc context registration H2G. In addition a workqueue and
process descriptor are setup during multi-lrc context registration as
these data structures are needed for multi-lrc submission.
v2:
(John Harrison)
- Move GuC specific fields into sub-struct
- Clean up WQ defines
- Add
Add logical engine mapping. This is required for split-frame, as
workloads need to be placed on engines in a logically contiguous manner.
v2:
(Daniel Vetter)
- Add kernel doc for new fields
v3
(Tvrtko)
- Update comment for new logical_mask field
Signed-off-by: Matthew Brost
---
Introduce context parent-child relationship. Once this relationship is
created all pinning / unpinning operations are directed to the parent
context. The parent context is responsible for pinning all of its'
children and itself.
This is a precursor to the full GuC multi-lrc implementation but
As discussed in [1] we are introducing a new parallel submission uAPI
for the i915 which allows more than 1 BB to be submitted in an execbuf
IOCTL. This is the implemenation for both GuC and execlists.
In addition to selftests in the series, an IGT is available implemented
in the first 4 patches
Cc'ing Dan Carpenter
On Fri, Oct 01, 2021 at 12:57:13PM +0300, Jani Nikula wrote:
On Fri, 01 Oct 2021, Chris Wilson wrote:
Quoting Lucas De Marchi (2021-10-01 08:40:41)
When trying to bring IS_ACTIVE to linux/kconfig.h I thought it wouldn't
provide much value just encapsulating it in a
== Series Details ==
Series: drm/i915/fbc: Don't nuke manually around flips (rev2)
URL : https://patchwork.freedesktop.org/series/89823/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10681_full -> Patchwork_21236_full
Am 04.10.21 um 12:50 schrieb Tvrtko Ursulin:
On 04/10/2021 11:44, Christian König wrote:
Am 04.10.21 um 12:34 schrieb Tvrtko Ursulin:
On 04/10/2021 10:53, Christian König wrote:
Am 04.10.21 um 11:29 schrieb Tvrtko Ursulin:
On 01/10/2021 11:05, Christian König wrote:
Abstract the
On Fri 01 Oct 10:11 CDT 2021, Sean Paul wrote:
> From: Sean Paul
>
> This patch adds the bindings for the MSM DisplayPort HDCP registers
> which are required to write the HDCP key into the display controller as
> well as the registers to enable HDCP authentication/key
> exchange/encryption.
>
On Fri 01 Oct 10:11 CDT 2021, Sean Paul wrote:
> From: Sean Paul
>
> This patch adds the bindings for the MSM DisplayPort HDCP registers
> which are required to write the HDCP key into the display controller as
> well as the registers to enable HDCP authentication/key
> exchange/encryption.
>
Hi Dave and Daniel,
Here goes an accumulated pull request. A special highlight to
the ADL-P (XE_LPD) and DG2 display support preparation and on
a big clean-up in the display portion of the driver.
Here goes drm-intel-next-2021-10-04:
Cross-subsystem Changes:
- fbdev/efifb: Release PCI device's
On Mon, Oct 04, 2021 at 10:50:00AM -0700, Matt Roper wrote:
> On Sat, Oct 02, 2021 at 01:01:31AM +0300, Ville Syrjälä wrote:
> > On Fri, Oct 01, 2021 at 02:08:15PM -0700, Matt Roper wrote:
> > > On Thu, Sep 30, 2021 at 10:09:42PM +0300, Ville Syrjala wrote:
> > > > From: Ville Syrjälä
> > > >
>
== Series Details ==
Series: drm/atomic: Add the crtc to affected crtc only if uapi.enable = true
(rev3)
URL : https://patchwork.freedesktop.org/series/87555/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10681_full -> Patchwork_21235_full
On Mon, Oct 04, 2021 at 06:02:21PM +0200, Hans de Goede wrote:
> Hi,
>
> On 10/4/21 5:37 PM, Ville Syrjälä wrote:
> > On Sat, Oct 02, 2021 at 06:36:18PM +0200, Hans de Goede wrote:
> >> Add support for eDP panels with a built-in privacy screen using the
> >> new drm_privacy_screen class.
> >>
>
On Tue, 14 Sep 2021, Nathan Chancellor wrote:
> i915 enables a wider set of warnings with '-Wall -Wextra' then disables
> several with cc-disable-warning. If an unknown flag gets added to
> KBUILD_CFLAGS when building with clang, all subsequent calls to
> cc-{disable-warning,option} will fail,
On Mon, Oct 04, 2021 at 03:04:01PM +, Gupta, Anshuman wrote:
>
>
> > -Original Message-
> > From: Ville Syrjälä
> > Sent: Monday, October 4, 2021 4:22 PM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Sean Paul ; Gupta, Anshuman
> > ; C, Ramalingam ; B S,
> > Karthik
> > Subject:
== Series Details ==
Series: drm/i915/tc: Delete bogus NULL check in intel_ddi_encoder_destroy()
URL : https://patchwork.freedesktop.org/series/95402/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10681_full -> Patchwork_21232_full
== Series Details ==
Series: drm/i915: Improve DP link training further (rev2)
URL : https://patchwork.freedesktop.org/series/95405/
State : failure
== Summary ==
Applying: drm/i915: Tweak the DP "max vswing reached?" condition
Applying: drm/i915: Show LTTPR in the TPS debug print
Applying:
From: Ville Syrjälä
I suppose intel_dp_dump_link_status() might be useful for diagnosing
link training failures. Hoever we only call from the channel EQ phase
currently. Let's call it from the CR phase as well.
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
A little bit more generic DP link training improvements before
we finally get to the actual per-lane drive settings PHY
programming stuff.
v2: CI is confused about sha1s for some reason
Ville Syrjälä (5):
drm/i915: Tweak the DP "max vswing reached?" condition
drm/i915:
From: Ville Syrjälä
Indicate which LTTPR we're currently attempting to train when
we print which training pattern we're using.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/g4x_dp.c | 2 +-
drivers/gpu/drm/i915/display/intel_dp_link_training.c | 11 +++
On Thu, Sep 30, 2021 at 10:09:43PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Since the VT-d vs. async flip issues are plaguing a wider range
> of supported hw let's try to minimize the impact on normal
> operation by flipping the relevant chicken bits on and off
> as needed. I
On Sat, Oct 02, 2021 at 01:01:31AM +0300, Ville Syrjälä wrote:
> On Fri, Oct 01, 2021 at 02:08:15PM -0700, Matt Roper wrote:
> > On Thu, Sep 30, 2021 at 10:09:42PM +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Looks like skl/bxt/derivatives also need the plane stride
> > >
From: Ville Syrjälä
Print out each DP vswing adjustment request we got from the RX.
Could help in diagnosing what's going on during link training.
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_dp_link_training.c | 27 +++
1 file changed, 27 insertions(+)
diff
From: Ville Syrjälä
Unify all debug prints during link training to include information
on both the encoder and the LTTPR. We unify the format to something
like "[ENCODER:1:FOO][LTTPR 1] Something something". Though not
sure if those brackets around the dp_phy just make it look like
line noise?
From: Ville Syrjälä
Currently we consider the max vswing reached when we transmit a
the max voltage level, but we don't consider pre-emphasis at all.
This kinda matches older DP specs that only had some vague text
about transmitting the maximum voltage swing. Latest versions
now say something
== Series Details ==
Series: drm/i915/fbc: Don't nuke manually around flips (rev2)
URL : https://patchwork.freedesktop.org/series/89823/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10681 -> Patchwork_21236
Summary
== Series Details ==
Series: CPU + GPU synchronised priority scheduling (rev2)
URL : https://patchwork.freedesktop.org/series/95294/
State : failure
== Summary ==
fatal: empty ident name (for <>) not allowed
Applying: effective and consolidated user experience. In other words why user
would
On Sat, Oct 02, 2021 at 06:36:18PM +0200, Hans de Goede wrote:
> Add support for eDP panels with a built-in privacy screen using the
> new drm_privacy_screen class.
>
> Changes in v2:
> - Call drm_connector_update_privacy_screen() from
> intel_enable_ddi_dp() / intel_ddi_update_pipe_dp()
On Sat, Oct 02, 2021 at 06:36:13PM +0200, Hans de Goede wrote:
> Add 2 drm_connector privacy-screen helper functions:
>
> 1. drm_connector_attach_privacy_screen_provider(), this function creates
> and attaches the standard privacy-screen properties and registers a
> generic notifier for
Hi,
On 10/4/21 5:37 PM, Ville Syrjälä wrote:
> On Sat, Oct 02, 2021 at 06:36:18PM +0200, Hans de Goede wrote:
>> Add support for eDP panels with a built-in privacy screen using the
>> new drm_privacy_screen class.
>>
>> Changes in v2:
>> - Call drm_connector_update_privacy_screen() from
>>
== Series Details ==
Series: drm/atomic: Add the crtc to affected crtc only if uapi.enable = true
(rev3)
URL : https://patchwork.freedesktop.org/series/87555/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10681 -> Patchwork_21235
On Sat, Oct 02, 2021 at 06:36:17PM +0200, Hans de Goede wrote:
> The upcoming privacy-screen support adds another check for
> deferring probe till some other drivers have bound first.
>
> Factor out the current vga_switcheroo_client_probe_defer() check
> into an intel_modeset_probe_defer()
Hi,
On 10/4/21 5:22 PM, Ville Syrjälä wrote:
> On Sat, Oct 02, 2021 at 06:36:13PM +0200, Hans de Goede wrote:
>> Add 2 drm_connector privacy-screen helper functions:
>>
>> 1. drm_connector_attach_privacy_screen_provider(), this function creates
>> and attaches the standard privacy-screen
On 24/09/2021 23:34, Umesh Nerlige Ramappa wrote:
With GuC handling scheduling, i915 is not aware of the time that a
context is scheduled in and out of the engine. Since i915 pmu relies on
this info to provide engine busyness to the user, GuC shares this info
with i915 for all engines using
> -Original Message-
> From: Ville Syrjälä
> Sent: Monday, October 4, 2021 4:22 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Sean Paul ; Gupta, Anshuman
> ; C, Ramalingam ; B S,
> Karthik
> Subject: i915 MST HDCP code looks broken
>
> Hi,
>
> I took a quick peek at
== Series Details ==
Series: drm/atomic: Add the crtc to affected crtc only if uapi.enable = true
(rev3)
URL : https://patchwork.freedesktop.org/series/87555/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
658485c7066a drm/atomic: Add the crtc to affected crtc only if
== Series Details ==
Series: drm/i915/tc: Delete bogus NULL check in intel_ddi_encoder_destroy()
URL : https://patchwork.freedesktop.org/series/95402/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10681 -> Patchwork_21232
From: Tvrtko Ursulin
Introduce the concept of context nice value which matches the process
nice.
We do this by extending the struct i915_sched_attr and add a helper
(i915_sched_attr_priority) to be used to convert to effective priority
when used by backend code and for priority sorting.
From: Tvrtko Ursulin
This is a somewhat early sketch of one of my ideas intended for early feedback
from the core scheduler experts. First and last two patches in the series are
the most interesting ones for people outside of i915. (Note I did not copy
everyone on all patches but just the cover
From: Tvrtko Ursulin
Implement a simple notifier chain via which interested parties can track
when process nice value changes. Simple because it is global so each user
would have to track which tasks it is interested in.
First intended use case are GPU drivers using task nice as priority hint
== Series Details ==
Series: drm/i915: Prefer struct_size over open coded arithmetic
URL : https://patchwork.freedesktop.org/series/95408/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
DESCEND objtool
CHK
== Series Details ==
Series: drm/i915: Improve DP link training further
URL : https://patchwork.freedesktop.org/series/95405/
State : failure
== Summary ==
Applying: drm/i915: Tweak the DP "max vswing reached?" condition
Applying: drm/i915: Show LTTPR in the TPS debug print
Applying:
From: Tvrtko Ursulin
A simple hash table of registered clients indexed by the task struct
pointer is kept to be used in a following patch.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 ++
drivers/gpu/drm/i915/i915_drm_client.c | 31
From: Tvrtko Ursulin
Code added in 71ed60112d5d ("drm/i915: Add kick_backend function to
i915_sched_engine") and ee242ca704d3 ("drm/i915/guc: Implement GuC
priority management") introduced some scheduling related vfuncs which
take integer request priority as argument.
Make them instead take
From: Tvrtko Ursulin
Make GEM contexts keep a reference to i915_drm_client for the whole of
of their lifetime which will come handy in following patches.
v2: Don't bother supporting selftests contexts from debugfs. (Chris)
v3 (Lucas): Finish constructing ctx before adding it to the list
v4
From: Tvrtko Ursulin
We soon want to start answering questions like how much GPU time is the
context belonging to a client which exited still using.
To enable this we start tracking all context belonging to a client on a
separate list.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Aravind
From: Tvrtko Ursulin
Tracking DRM clients more explicitly will allow later patches to
accumulate past and current GPU usage in a centralised place and also
consolidate access to owning task pid/name.
Unique client id is also assigned for the purpose of distinguishing/
consolidating between
From: Tvrtko Ursulin
Connect i915 with the process nice change notifier so that our scheduling
can react to runtime adjustments, on top of previously added nice value
inheritance at context create time.
To achieve this we use the previously added map of clients per owning
tasks in combination
From: Ville Syrjälä
Apparently we have discovered another way to hit the dreaded
top of screen FBC corruption on GLK. Previously we thought it
was limited to some combination of FBC nuke+disable+plane update
during the same frame, for which we have the extra vblank wait
as a workaround. But
From: Ville Syrjälä
Move more of the common stuff one level up from
intel_fbc_hw_(de)activate().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fbc.c | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git
From: Ville Syrjälä
Let's see how the glk is behaving these days...
Ville Syrjälä (2):
drm/i915/fbc: Hoist more stuff out from intel_fbc_hw_(de)activate()
drm/i915/fbc: Don't nuke manually around flips
drivers/gpu/drm/i915/display/intel_fbc.c | 36 +---
1 file changed,
On 04/10/2021 13:59, Christian König wrote:
Am 04.10.21 um 12:50 schrieb Tvrtko Ursulin:
On 04/10/2021 11:44, Christian König wrote:
Am 04.10.21 um 12:34 schrieb Tvrtko Ursulin:
On 04/10/2021 10:53, Christian König wrote:
Am 04.10.21 um 11:29 schrieb Tvrtko Ursulin:
On 01/10/2021
On 01/10/2021 11:05, Christian König wrote:
Just exercising a very minor subset of the functionality, but already
proven useful.
Signed-off-by: Christian König
---
drivers/dma-buf/Makefile | 3 +-
drivers/dma-buf/selftests.h | 1 +
drivers/dma-buf/st-dma-resv.c | 164
In case of a modeset where a mode gets split across mutiple CRTCs
in the driver specific implementation (bigjoiner in i915) we wrongly count
the affected CRTCs based on the drm_crtc_mask and indicate the stolen CRTC as
an affected CRTC in atomic_check_only().
This triggers a warning since affected
Am 04.10.21 um 11:29 schrieb Tvrtko Ursulin:
On 01/10/2021 11:05, Christian König wrote:
Abstract the complexity of iterating over all the fences
in a dma_resv object.
The new loop handles the whole RCU and retry dance and
returns only fences where we can be sure we grabbed the
right one.
Am 04.10.21 um 12:34 schrieb Tvrtko Ursulin:
On 04/10/2021 10:53, Christian König wrote:
Am 04.10.21 um 11:29 schrieb Tvrtko Ursulin:
On 01/10/2021 11:05, Christian König wrote:
Abstract the complexity of iterating over all the fences
in a dma_resv object.
The new loop handles the whole
As noted in the "Deprecated Interfaces, Language Features, Attributes,
and Conventions" documentation [1], size calculations (especially
multiplication) should not be performed in memory allocator (or similar)
function arguments due to the risk of them overflowing. This could lead
to values
On Mon, Oct 04, 2021 at 04:36:29AM -0700, Manasi Navare wrote:
> In case of a modeset where a mode gets split across mutiple CRTCs
> in the driver specific implementation (bigjoiner in i915) we wrongly count
> the affected CRTCs based on the drm_crtc_mask and indicate the stolen CRTC as
> an
In case of a modeset where a mode gets split across mutiple CRTCs
in the driver specific implementation (bigjoiner in i915) we wrongly count
the affected CRTCs based on the drm_crtc_mask and indicate the stolen CRTC as
an affected CRTC in atomic_check_only().
This triggers a warning since affected
From: Ville Syrjälä
I suppose intel_dp_dump_link_status() might be useful for diagnosing
link training failures. Hoever we only call from the channel EQ phase
currently. Let's call it from the CR phase as well.
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Print out each DP vswing adjustment request we got from the RX.
Could help in diagnosing what's going on during link training.
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_dp_link_training.c | 27 +++
1 file changed, 27 insertions(+)
diff
From: Ville Syrjälä
Unify all debug prints during link training to include information
on both the encoder and the LTTPR. We unify the format to something
like "[ENCODER:1:FOO][LTTPR 1] Something something". Though not
sure if those brackets around the dp_phy just make it look like
line noise?
From: Ville Syrjälä
Indicate which LTTPR we're currently attempting to train when
we print which training pattern we're using.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/g4x_dp.c | 2 +-
drivers/gpu/drm/i915/display/intel_dp_link_training.c | 11 +++
From: Ville Syrjälä
Currently we consider the max vswing reached when we transmit a
the max voltage level, but we don't consider pre-emphasis at all.
This kinda matches older DP specs that only had some vague text
about transmitting the maximum voltage swing. Latest versions
now say something
1 - 100 of 119 matches
Mail list logo
