> -Original Message-
> From: Intel-gfx On Behalf Of Dave
> Airlie
> Sent: maanantai 4. lokakuuta 2021 3.33
> To: Ville Syrjälä
> Cc: Nikula, Jani ; Intel Graphics Development g...@lists.freedesktop.org>; Dave Airlie ; Sarvela, Tomi P
>
> Subject: Re: [Intel-gfx] [PATCH 01/24] drm/i91
On Fri, 24 Sep 2021, Ville Syrjälä wrote:
> On Tue, Sep 21, 2021 at 06:50:39PM -0700, Matthew Brost wrote:
>> From: Hugh Dickins
>>
>> 5.15-rc1 crashes with blank screen when booting up on two ThinkPads
>> using i915. Bisections converge convincingly, but arrive at different
>> and surprising "
On Sat, 02 Oct 2021, Hugh Dickins wrote:
> On Sat, 2 Oct 2021, Linus Torvalds wrote:
>> On Sat, Oct 2, 2021 at 5:17 AM Steven Rostedt wrote:
>> > On Sat, 2 Oct 2021 03:17:29 -0700 (PDT)
>> > Hugh Dickins wrote:
>> >
>> > > Yes (though bisection doesn't work right on this one): the fix
>> >
>> >
> From: Ville Syrjälä
> On Wed, Sep 29, 2021 at 01:57:45AM +0300, Jani Nikula wrote:
> > From: Dave Airlie
> >
> > constify it while here. drop the put function since it was never
> > overloaded and always has done the same thing, no point in
> > indirecting it for show.
> >
> > Reviewed-by: Jani
On Mon, 04 Oct 2021, Dave Airlie wrote:
> From: Dave Airlie
>
> This was causing infinite recursion on snb/ivb.
>
> Fixes: 5716c8c6f4b6 ("drm/i915/uncore: split the fw get function into
> separate vfunc")
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/i915/intel_uncore.c | 2 +-
> 1 file
On Mon, 04 Oct 2021, "Saarinen, Jani" wrote:
>> -Original Message-
>> From: Intel-gfx On Behalf Of Dave
>> Airlie
>> Sent: maanantai 4. lokakuuta 2021 3.33
>> To: Ville Syrjälä
>> Cc: Nikula, Jani ; Intel Graphics Development > g...@lists.freedesktop.org>; Dave Airlie ; Sarvela, Tomi
>
On Sat, Oct 02, 2021 at 07:28:02PM +0200, Fernando Ramos wrote:
> On 21/10/02 09:13AM, Fernando Ramos wrote:
> > On 21/10/02 05:30AM, Ville Syrjälä wrote:
> > > On Sat, Oct 02, 2021 at 01:05:47AM +0300, Ville Syrjälä wrote:
> > > > On Fri, Oct 01, 2021 at 04:48:15PM -0400, Sean Paul wrote:
> > > >
On 01/10/2021 16:48, Peter Zijlstra wrote:
On Fri, Oct 01, 2021 at 11:32:16AM +0100, Tvrtko Ursulin wrote:
On 01/10/2021 10:04, Tvrtko Ursulin wrote:
Hi Peter,
On 30/09/2021 19:33, Peter Zijlstra wrote:
On Thu, Sep 30, 2021 at 06:15:47PM +0100, Tvrtko Ursulin wrote:
void set_user_nice
On Sun, Oct 03, 2021 at 12:32:14AM +0200, Fernando Ramos wrote:
> On 21/10/02 09:13AM, Fernando Ramos wrote:
> >
> > Sean, could you revert the whole patch series? I'll have a deeper look into
> > the
> > patch set and come up with a v3 where all these issues will be addressed.
> >
>
> Hi Sean,
On Mon, Oct 04, 2021 at 09:12:37AM +0100, Tvrtko Ursulin wrote:
> On 01/10/2021 16:48, Peter Zijlstra wrote:
> > Hmm? That's for normalize_rt_tasks() only, right? Just don't have it
> > call the notifier in that special case (that's a magic sysrq thing
> > anyway).
>
> You mean my talk about task
On Mon, 04 Oct 2021, Ville Syrjälä wrote:
> On Sun, Oct 03, 2021 at 12:32:14AM +0200, Fernando Ramos wrote:
>> On 21/10/02 09:13AM, Fernando Ramos wrote:
>> >
>> > Sean, could you revert the whole patch series? I'll have a deeper look
>> > into the
>> > patch set and come up with a v3 where all
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.
v2: fix accessing the shared fences while they m
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 RCU and retry dance and
returns only fences wher
On Tue, Apr 27, 2021 at 10:58:07AM +0200, Daniel Vetter wrote:
> On Mon, Apr 26, 2021 at 08:18:39PM +0300, Ville Syrjälä wrote:
> > On Mon, Apr 26, 2021 at 06:08:59PM +0200, Daniel Vetter wrote:
> > > On Thu, Apr 22, 2021 at 04:11:22PM +0300, Ville Syrjälä wrote:
> > > > On Thu, Apr 22, 2021 at 11:
The "digi_port" pointer can't be NULL and we have already dereferenced
it so checking for NULL is not necessary. Delete the check.
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/i915/display/intel_ddi.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915
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 complexity of iterating over all the fences
in a dma_r
Hi,
I took a quick peek at intel_dp_add_mst_connector() the other day and
noticed that it calls intel_dp_hdcp_init() and passes in the SST
dig_port. And digging in a bit further that seems to clobber all
kinds of things in dig_port->hdcp_port_data. This looks rather
broken to me.
So has anyone ac
On Tue, Jul 20, 2021 at 03:44:49PM +0200, Daniel Vetter wrote:
> On Thu, Jul 15, 2021 at 09:49:51PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Quite a few places are hand rolling the modeset lock backoff dance.
> > Let's suck that into a helper macro that is easier to use without
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.
Ville Syrjälä (5):
drm/i915: Tweak the DP "max vswing reached?" condition
drm/i915: Show LTTPR in the TPS debug print
drm/i915: Pri
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 vag
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ä
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? I'
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 --g
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ä
---
drivers/gpu/drm/i915/display/intel_dp_link_trainin
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
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 affect
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 wrappin
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 RCU
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.
v2:
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
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 ++
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 11:05,
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,
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 a/drivers/gpu/drm/i915/display
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 looks
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 wi
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 multi
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 Iddamse
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 (Ram)
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 stru
== 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: drm/i915:
== 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 include/generated/comp
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
wh
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 l
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.
Context
== 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
S
== 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 uapi.enab
> -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 intel_dp_add_mst
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 sha
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 propertie
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() helper,
== 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
==
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
>> intel
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 generating
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() instead
== 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 n
== 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
---
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 vag
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? I'
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 --g
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
> > > str
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 presume
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ä
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: S
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ä
---
drivers/gpu/drm/i915/display/intel_dp_link_trainin
== 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: dr
== 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
=
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: i
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, mea
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.
> >>
> >>
== 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 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ä
> > > >
> >
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 r
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.
>
>
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 complexit
== 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
Summa
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 boolea
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 [
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 alig
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
---
drivers/gp
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 com
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:
(
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 context.
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 a/dri
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 is
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 coales
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
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 t
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
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
- Add
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 th
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 +-
drive
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:
(Dani
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 compari
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 fe
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(-)
delet
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 batches
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&rev=1
media UMD: https://github.com/intel/media-driver/pull/1252
v2:
(Daniel Vetter)
- Add IGT l
1 - 100 of 121 matches
Mail list logo
