== Series Details ==
Series: Enable HDR on Gen9 devices with lspcon hdr capability (rev2)
URL : https://patchwork.freedesktop.org/series/75148/
State : failure
== Summary ==
Applying: drm/i915/display: Add HDR Capability detection for LSPCON
Applying: drm/i915/display: Enable HDR on gen9 devic
On 2020-03-27 at 11:41:04 +0530, Vipin Anand wrote:
> From: Uma Shankar
>
> LSPCON firmware exposes HDR capability through LPCON_CAPABILITIES
> DPCD register. LSPCON implementations capable of supporting
> HDR set HDR_CAPABILITY bit in LSPCON_CAPABILITIES to 1. This patch
> reads the same, detect
From: Uma Shankar
Enable Colorspace as BT2020 if driving HDR content.Sending Colorimetry
data for HDR using AVI infoframe. LSPCON firmware expects this and though
SOC drives DP, for HDMI panel AVI infoframe is sent to the LSPCON device
which transfers the same to HDMI sink.
Signed-off-by: Uma Sh
From: Uma Shankar
LSPCON firmware exposes HDR capability through LPCON_CAPABILITIES
DPCD register. LSPCON implementations capable of supporting
HDR set HDR_CAPABILITY bit in LSPCON_CAPABILITIES to 1. This patch
reads the same, detects the HDR capability and adds this to
intel_lspcon struct.
Sign
From: Uma Shankar
Send Dynamic Range and Mastering Infoframe (DRM for HDR metadata)
as SDP packet to LSPCON following the DP spec. LSPCON receives the
same and sends it to HDMI sink.
v2: Suppressed some warnings. No functional change.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_atomic_
From: Uma Shankar
Attach HDR property for Gen9 devices with MCA LSPCON
chips.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_lspcon.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c
b/drivers/gpu/drm/i915/display/intel_ls
rebased
Uma Shankar (6):
drm/i915/display: Add HDR Capability detection for LSPCON
drm/i915/display: Enable HDR on gen9 devices with MCA Lspcon
drm/i915/display: Attach HDR property for capable Gen9 devices
drm/i915/display: Set HDR Infoframe for HDR capable LSPCON devices
drm/i915/displ
From: Uma Shankar
Gen9 hardware supports HDMI2.0 through LSPCON chips.
Extending HDR support for MCA LSPCON based GEN9 devices.
SOC will drive LSPCON as DP and send HDR metadata as standard
DP SDP packets. LSPCON will be set to operate in PCON mode,
will receive the metadata and create Dynamic R
From: Uma Shankar
Blanking needs to be reduced to incorporate DP and HDMI timing/link
bandwidth limitations for CEA modes (4k@60 at 10 bpp). DP can drive
17.28Gbs while 4k modes (VIC97 etc) at 10 bpp required 17.8 Gbps.
This will cause mode to blank out. Reduced Htotal by shortening the
back porc
this patch adds hdr capabilities checks for Gen9 devices with
lspcon support.
Signed-off-by: Vipin Anand
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 17 +
drivers/gpu/drm/i915/display/intel_lspcon.c | 9 +++--
2 files changed, 20 insertions(+), 6 deletions(-)
diff --g
== Series Details ==
Series: Enable HDR on Gen9 devices with lspcon hdr capability
URL : https://patchwork.freedesktop.org/series/75148/
State : failure
== Summary ==
Applying: drm/i915/display: Add HDR Capability detection for LSPCON
Applying: drm/i915/display: Enable HDR on gen9 devices with
this patch adds hdr capabilities checks for Gen9 devices with
lspcon support.
Signed-off-by: Vipin Anand
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 17 +
drivers/gpu/drm/i915/display/intel_lspcon.c | 9 +++--
2 files changed, 20 insertions(+), 6 deletions(-)
diff --g
From: Uma Shankar
Gen9 hardware supports HDMI2.0 through LSPCON chips.
Extending HDR support for MCA LSPCON based GEN9 devices.
SOC will drive LSPCON as DP and send HDR metadata as standard
DP SDP packets. LSPCON will be set to operate in PCON mode,
will receive the metadata and create Dynamic R
From: Uma Shankar
Send Dynamic Range and Mastering Infoframe (DRM for HDR metadata)
as SDP packet to LSPCON following the DP spec. LSPCON receives the
same and sends it to HDMI sink.
v2: Suppressed some warnings. No functional change.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_atomic_
Initial patch series submitted https://patchwork.freedesktop.org/series/68081/
this patch series add hdr support for GLK platform, I have added patch to
add checks for all Gen9 platforms with lspcon hdr capability.
Uma Shankar (6):
drm/i915/display: Add HDR Capability detection for LSPCON
drm
From: Uma Shankar
LSPCON firmware exposes HDR capability through LPCON_CAPABILITIES
DPCD register. LSPCON implementations capable of supporting
HDR set HDR_CAPABILITY bit in LSPCON_CAPABILITIES to 1. This patch
reads the same, detects the HDR capability and adds this to
intel_lspcon struct.
Sign
From: Uma Shankar
Blanking needs to be reduced to incorporate DP and HDMI timing/link
bandwidth limitations for CEA modes (4k@60 at 10 bpp). DP can drive
17.28Gbs while 4k modes (VIC97 etc) at 10 bpp required 17.8 Gbps.
This will cause mode to blank out. Reduced Htotal by shortening the
back porc
From: Uma Shankar
Enable Colorspace as BT2020 if driving HDR content.Sending Colorimetry
data for HDR using AVI infoframe. LSPCON firmware expects this and though
SOC drives DP, for HDMI panel AVI infoframe is sent to the LSPCON device
which transfers the same to HDMI sink.
Signed-off-by: Uma Sh
From: Uma Shankar
Attach HDR property for Gen9 devices with MCA LSPCON
chips.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_lspcon.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_lspcon.c
b/drivers/gpu/drm/i915/display/intel_ls
On Thu, 26 Mar 2020 02:09:34 -0700, Lionel Landwerlin wrote:
>
> On 26/03/2020 06:43, Ashutosh Dixit wrote:
> > It is wrong to block the user thread in the next poll when OA data is
> > already available which could not fit in the user buffer provided in
> > the previous read. In several cases the
== Series Details ==
Series: drm/i915/tgl: Make Wa_14010229206 permanent
URL : https://patchwork.freedesktop.org/series/75139/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8197 -> Patchwork_17107
Summary
---
**SUCCE
On Thu, 26 Mar 2020 11:02:46 -0700, Umesh Nerlige Ramappa wrote:
> On Wed, Mar 25, 2020 at 06:52:52PM -0700, Dixit, Ashutosh wrote:
> > On Wed, 25 Mar 2020 17:32:35 -0700, Umesh Nerlige Ramappa wrote:
> >>
> >> On Wed, Mar 25, 2020 at 11:20:19AM -0700, Ashutosh Dixit wrote:
> >> >
> >> > +/
== Series Details ==
Series: series starting with [1/2] drm/i915/execlists: Prevent GPU death on
ELSP[1] promotion to idle context
URL : https://patchwork.freedesktop.org/series/75138/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8197 -> Patchwork_17106
=
== Series Details ==
Series: series starting with [1/2] drm/i915/execlists: Prevent GPU death on
ELSP[1] promotion to idle context
URL : https://patchwork.freedesktop.org/series/75137/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8197 -> Patchwork_17105
=
== Series Details ==
Series: series starting with [1/2] drm/i915/execlists: Prevent GPU death on
ELSP[1] promotion to idle context
URL : https://patchwork.freedesktop.org/series/75138/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d6626ef65d6d drm/i915/execlists: Prevent GPU d
This workaround now applies to all steppings, not just A0.
Wa_1409085225 is a temporary A0-only W/A however it is
identical to Wa_14010229206 and hence the combined workaround
is made permanent.
Bspec: 52890
Signed-off-by: Swathi Dhanavanthri
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 11
== Series Details ==
Series: series starting with [1/2] drm/i915/execlists: Prevent GPU death on
ELSP[1] promotion to idle context
URL : https://patchwork.freedesktop.org/series/75137/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
5868edb0b7b7 drm/i915/execlists: Prevent GPU d
Upon a GPU reset, we copy the default context image over top of the
guilty image. This will rollback the CTX_TIMESTAMP register to before
our value of ce->runtime.last. Reset both back to 0 so that we do not
encounter an underflow on the next schedule out after resume.
This should not be a huge is
In what seems remarkably similar to the w/a required to not reload an
idle context with HEAD==TAIL, it appears we must prevent the HW from
switching to an idle context in ELSP[1], while simultaneously trying to
preempt the HW to run another context and a continuation of the idle
context (which is n
In what seems remarkably similar to the w/a required to not reload an
idle context with HEAD==TAIL, it appears we must prevent the HW from
switching to an idle context in ELSP[1], while simultaneously trying to
preempt the HW to run another context and a continuation of the idle
context (which is n
Upon a GPU reset, we copy the default context image over top of the
guilty image. This will rollback the CTX_TIMESTAMP register to before
our value of ce->runtime.last. Reset both back to 0 so that we do not
encounter an underflow on the next schedule out after resume.
This should not be a huge is
On Thu, 26 Mar 2020, Nathan Chancellor wrote:
> This is the only warning on an x86_64 defconfig build. Apologies if we
> are being too persistent or nagging but we need guidance from the i915
> maintainers on which solution they would prefer so it can be picked up.
> I understand you all are busy
== Series Details ==
Series: drm/i915/execlists: Prevent GPU death on ELSP[1] promotion to idle
context (rev2)
URL : https://patchwork.freedesktop.org/series/75130/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8195 -> Patchwork_17104
=
== Series Details ==
Series: drm/i915/execlists: Prevent GPU death on ELSP[1] promotion to idle
context (rev2)
URL : https://patchwork.freedesktop.org/series/75130/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
f75f1d1d76f8 drm/i915/execlists: Prevent GPU death on ELSP[1] prom
== Series Details ==
Series: SAGV support for Gen12+ (rev3)
URL : https://patchwork.freedesktop.org/series/75129/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8195 -> Patchwork_17103
Summary
---
**SUCCESS**
No re
== Series Details ==
Series: SAGV support for Gen12+ (rev3)
URL : https://patchwork.freedesktop.org/series/75129/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ad8810ff373a drm/i915: Start passing latency as parameter
930754956920 drm/i915: Eliminate magic numbers "0" and "1" f
== Series Details ==
Series: Re-org uC debugfs files and move them under GT (rev3)
URL : https://patchwork.freedesktop.org/series/74051/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8195 -> Patchwork_17102
Summary
---
== Series Details ==
Series: drm/i915/selftests: Check timeout before flush and cond checks
URL : https://patchwork.freedesktop.org/series/75126/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8195 -> Patchwork_17100
Summary
== Series Details ==
Series: Re-org uC debugfs files and move them under GT (rev3)
URL : https://patchwork.freedesktop.org/series/74051/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e19786b07259 drm/i915/gt: allow setting generic data pointer
72a498f33e07 drm/i915/guc: drop st
== Series Details ==
Series: drm/i915/execlists: Explicitly reset both reg and context runtime
URL : https://patchwork.freedesktop.org/series/75127/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
DESCEND objtool
CHK include/gen
== Series Details ==
Series: series starting with [01/12] drm/i915/selftests: Add request throughput
measurement to perf
URL : https://patchwork.freedesktop.org/series/75124/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8195 -> Patchwork_17099
===
On Mon, Mar 16, 2020 at 02:41:23PM -0700, Nick Desaulniers wrote:
> On Fri, Feb 14, 2020 at 7:36 AM Michel Dänzer wrote:
> >
> > On 2020-02-14 12:49 p.m., Jani Nikula wrote:
> > > On Fri, 14 Feb 2020, Chris Wilson wrote:
> > >> Quoting Jani Nikula (2020-02-14 06:36:15)
> > >>> On Thu, 13 Feb 2020
== Series Details ==
Series: series starting with [01/12] drm/i915/selftests: Add request throughput
measurement to perf
URL : https://patchwork.freedesktop.org/series/75124/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
1d8f9dafbff4 drm/i915/selftests: Add request throughput
== Series Details ==
Series: drm/i915: Differentiate between aliasing-ppgtt and ggtt pinning (rev2)
URL : https://patchwork.freedesktop.org/series/75078/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8195 -> Patchwork_17098
In what seems remarkably similar to the w/a required to not reload an
idle context with HEAD==TAIL, it appears we must prevent the HW from
switching to an idle context in ELSP[1], while simultaneously trying to
preempt the HW to run another context and a continuation of the idle
context (which is n
In what seems remarkably similar to the w/a required to not reload an
idle context with HEAD==TAIL, it appears we must prevent the HW from
switching to an idle context in ELSP[1], while simultaneously trying to
preempt the HW to run another context and a continuation of the idle
context (which is n
== Series Details ==
Series: drm/i915: Differentiate between aliasing-ppgtt and ggtt pinning (rev2)
URL : https://patchwork.freedesktop.org/series/75078/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
39b95b621dfc drm/i915: Differentiate between aliasing-ppgtt and ggtt pinning
-
== Series Details ==
Series: i915 lpsp support for lpsp igt (rev5)
URL : https://patchwork.freedesktop.org/series/74648/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8195 -> Patchwork_17097
Summary
---
**SUCCESS**
Let's refactor the whole SAGV logic, moving
the main calculations from intel_can_enable_sagv
to intel_compute_sagv_mask, which also handles
this in a unified way calling gen specific
functions to evaluate if SAGV is allowed for
each crtc. If crtc sagv mask have been changed
we serialize access and
According to BSpec 53998, we should try to
restrict qgv points, which can't provide
enough bandwidth for desired display configuration.
Currently we are just comparing against all of
those and take minimum(worst case).
v2: Fixed wrong PCode reply mask, removed hardcoded
values.
v3: Forbid si
Flip the switch and enable SAGV support
for Gen12 also.
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/intel_pm.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 6e4d64b626f8..4c278493559a 100644
--- a/dr
That is a preparation patch before next one where we
introduce old_bw_state and a bunch of other changes
as well.
In a review comment it was suggested to split out
at least that renaming into a separate patch, what
is done here.
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/display
For Gen11+ platforms BSpec suggests disabling specific
QGV points separately, depending on bandwidth limitations
and current display configuration. Thus it required adding
a new PCode request for disabling QGV points and some
refactoring of already existing SAGV code.
Also had to refactor intel_can
According to many computer science sources - magic values
in code _are_ _bad_. For many reasons: the reason is that "0"
or "1" or whatever magic values confuses and doesn't give any
info why this parameter is this value and what it's meaning
is.
I renamed "0" to COLOR_PLANE_Y and "1" to COLOR_PLANE
For future Gen12 SAGV implementation we need to
seemlessly alter wm levels calculated, depending
on whether we are allowed to enable SAGV or not.
So this accessor will give additional flexibility
to do that.
Currently this accessor is still simply working
as "pass-through" function. This will be
Let's refactor the whole SAGV logic, moving
the main calculations from intel_can_enable_sagv
to intel_compute_sagv_mask, which also handles
this in a unified way calling gen specific
functions to evaluate if SAGV is allowed for
each crtc. If crtc sagv mask have been changed
we serialize access and
We need a new PCode request commands and reply codes
to be added as a prepartion patch for QGV points
restricting for new SAGV support.
v2: - Extracted those changes into separate patch
(Ville Syrjälä)
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/i915_reg.h | 4
We need to start passing memory latency as a
parameter when calculating plane wm levels,
as latency can get changed in different
circumstances(for example with or without SAGV).
So we need to be more flexible on that matter.
v2: Changed latency type from u32 to unsigned int(Ville Syrjälä)
Reviewe
Add correspondent helpers to be able to get old/new bandwidth
global state object.
v2: - Fixed typo in function call
v3: - Changed new functions naming to use convention proposed
by Jani Nikula, i.e intel_bw_* in intel_bw.c file.
v4: - Change function naming back to intel_atomic* pattern,
Addressing one of the comments, recommending to extract platform
specific code from intel_can_enable_sagv as a preparation, before
we are going to add support for tgl+.
Current code in intel_can_enable_sagv is valid only for skl,
so this patch adds also proper support for icl, subsequent
patches w
According to BSpec 53998, we should try to
restrict qgv points, which can't provide
enough bandwidth for desired display configuration.
Currently we are just comparing against all of
those and take minimum(worst case).
v2: Fixed wrong PCode reply mask, removed hardcoded
values.
v3: Forbid si
Move the printers to the respective files for clarity. The
guc_load_status debugfs has been squashed in the guc_info one, has
having separate ones wasn't very useful. The HuC debugfs has been
renamed huc_info to match.
v2: keep printing HUC_STATUS2 (Tony), avoid const->non-const
container_of (
We need to keep the GuC error logs around to debug the load failure,
so we can't clean them in the error unwind, which includes uc_fini().
Moving the cleanup to driver remove ensures that the logs stick around
long enough for us to dump them.
v2: reword commit msg (John)
Signed-off-by: Daniele Ce
From: Andi Shyti
When registering debugfs files the intel gt debugfs library
forces a 'struct *gt' private data on the caller.
To be open to different usages make the new
"intel_gt_debugfs_register_files()"[*] function more generic by
converting the 'struct *gt' pointer to a 'void *' type.
I ta
uC is a component of the GT, so it makes sense for the uC debugfs files
to be in the GT folder. A subfolder has been used to keep the same
structure we have for the code.
v2: use intel_* prefix (Jani), rebase on new gt_debugfs_register_files,
fix permissions for writable debugfs files.
v3: Re
Minor changes applied to patch 5, which is the only one missing a
review.
As multiple people have noted, intel_gt_debugfs_register_files is
now generic enough to be pulled out of gt/. Andi has patches for that
and will follow up after this series is merged.
Cc: Andi Shyti
Cc: Michal Wajdeczko
C
We currently initialize HuC support based on GuC being enabled in
modparam; this means that huc_is_supported() can return false on HW that
does have a HuC when enable_guc=0. The rationale for this behavior is
that HuC requires GuC for authentication and therefore is not supported
by itself. However
The pool will be private to GuC in the new submission scheme, so we
won't be able to print it and we can just drop the current legacy code.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Cc: John Harrison
Cc: Matthew Brost
Reviewed-by: Andi Shyti
---
drivers/gpu/drm/i915/i915_deb
Upon a GPU reset, we copy the default context image over top of the
guilty image. This will rollback the CTX_TIMESTAMP register to before
our value of ce->runtime.last. Reset both back to 0 so that we do not
encounter an underflow on the next schedule out after resume.
This should not be a huge is
On Wed, Mar 25, 2020 at 06:52:52PM -0700, Dixit, Ashutosh wrote:
On Wed, 25 Mar 2020 17:32:35 -0700, Umesh Nerlige Ramappa wrote:
On Wed, Mar 25, 2020 at 11:20:19AM -0700, Ashutosh Dixit wrote:
> It is wrong to block the user thread in the next poll when OA data is
> already available which cou
> -Original Message-
> From: Ville Syrjälä
> Sent: Thursday, March 26, 2020 9:47 PM
> To: Shankar, Uma
> Cc: intel-gfx@lists.freedesktop.org; Maarten Lankhorst
> ; Kai Vehmanen
> ; Souza; Souza, Jose ;
> Khor, Swee Aun
> Subject: Re: [PATCH] drm/i915/display: Fix mode private_flags com
== Series Details ==
Series: series starting with [01/21] Revert "drm/i915/gem: Drop relocation
slowpath"
URL : https://patchwork.freedesktop.org/series/75115/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8194 -> Patchwork_17096
==
== Series Details ==
Series: series starting with [01/21] Revert "drm/i915/gem: Drop relocation
slowpath"
URL : https://patchwork.freedesktop.org/series/75115/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d083289b34df Revert "drm/i915/gem: Drop relocation slowpath"
-:78: WARN
== Series Details ==
Series: drm:i915:display: add checks for Gen9 devices with hdr capability
URL : https://patchwork.freedesktop.org/series/75114/
State : failure
== Summary ==
Applying: drm:i915:display: add checks for Gen9 devices with hdr capability
error: sha1 information is lacking or u
On Wed, 25 Mar 2020 at 21:23, George Spelvin wrote:
>
> igt_mm_config() calls ilog2() on the (pseudo)random 21-bit number
> s>>12. Once in 2 million seeds, this is zero and ilog2 summons
> the nasal demons.
>
> There was an attempt to handle this case with a max(), but that's
> too late; ms could
On Thu, 2020-03-05 at 15:12 -0500, Sean Paul wrote:
> 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
>
> Changes in v4:
> -Added
Allow a bit of leniency for the CPU scheduler to be distracted while we
flush the tasklet and so ensure that we always check the status of the
request once more before timing out.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 11 +--
1 file changed, 5 insertion
On Thu, Mar 26, 2020 at 01:19:28PM +0530, Uma Shankar wrote:
> This patch fixes the private_flags of mode to be checked and
> compared against uapi.mode and not from hw.mode. This helps
> properly trigger modeset at boot if desired by driver.
>
> It helps resolve audio_codec initialization issues
On Thu, Mar 26, 2020 at 08:45:59PM +0530, Bharadiya,Pankaj wrote:
> On Tue, Mar 24, 2020 at 06:46:10PM +0200, Ville Syrjälä wrote:
> > On Tue, Mar 24, 2020 at 03:32:09PM +, Laxminarayan Bharadiya, Pankaj
> > wrote:
> > >
> > >
> > > > -Original Message-
> > > > From: Ville Syrjälä
>
On Tue, Mar 24, 2020 at 06:46:10PM +0200, Ville Syrjälä wrote:
> On Tue, Mar 24, 2020 at 03:32:09PM +, Laxminarayan Bharadiya, Pankaj
> wrote:
> >
> >
> > > -Original Message-
> > > From: Ville Syrjälä
> > > Sent: 23 March 2020 20:18
> > > To: Laxminarayan Bharadiya, Pankaj
> > >
>
On Mon, Mar 23, 2020 at 03:48:59PM +0100, Daniel Vetter wrote:
> Hi all,
>
> Another round, another set of polish all over. intel-gfx-ci was happy last
> time around (after I fixed a fumble), so really just review and comments
> needed now. There's still a few patches at the beginning holding the
Inside dma-fence-chain, we use a cmpxchg on an RCU-protected pointer. To
avoid the sparse warning for using the RCU pointer directly, we have to
cast away the __rcu annotation. However, we don't need to use void*
everywhere and can stick to the dma_fence*.
Signed-off-by: Chris Wilson
Reviewed-by:
Allow the callers to supply a dma-fence-proxy for asynchronous waiting on
future fences.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_syncobj.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 4
We wish that the scheduler emit the context modification commands prior
to enabling the oa_config, for which we must explicitly inform it of the
ordering constraints. This is especially important as we now wait for
the final oa_config setup to be completed and as this wait may be on a
distinct cont
Let userspace know if they can trust timeslicing by including it as part
of the I915_PARAM_HAS_SCHEDULER::I915_SCHEDULER_CAP_TIMESLICING
v2: Only declare timeslicing if we can safely preempt userspace.
Fixes: 8ee36e048c98 ("drm/i915/execlists: Minimalistic timeslicing")
Signed-off-by: Chris Wilso
If a syncobj has not yet been assigned, treat it as a future fence and
install and wait upon a dma-fence-proxy. The proxy will be replace by
the real fence later, and that fence will be responsible for signaling
our waiter.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem_execbuffer
Often we need to create a fence for a future event that has not yet been
associated with a fence. We can store a proxy fence, a placeholder, in
the timeline and replace it later when the real fence is known. Any
listeners that attach to the proxy fence will automatically be signaled
when the real f
Fixes: a88b6e4cbafd ("drm/i915: Allow specification of parallel execbuf")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Lionel Landwerlin
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 10 +++---
include/uapi/drm/i915_drm.h| 7 ---
2 files changed, 11 ins
Under ideal circumstances, the driver should be able to keep the GPU
fully saturated with work. Measure how close to ideal we get under the
harshest of conditions with no user payload.
v2: Also measure throughput using only one thread.
Signed-off-by: Chris Wilson
---
.../drm/i915/selftests/i915
Whenever we walk along the dma-fence-chain, we prune signaled links to
keep the chain nice and tidy. This leads to situations where we can
prune a link and report the earlier fence as the target seqno --
violating our own consistency checks that the seqno is not more advanced
than the last element
If we find ourselves waiting on a MI_SEMAPHORE_WAIT, either within the
user batch or in our own preamble, the engine raises a
GT_WAIT_ON_SEMAPHORE interrupt. We can unmask that interrupt and so
respond to a semaphore wait by yielding the timeslice, if we have
another context to yield to!
The only
A few very simple testcases to exercise the dma-fence-chain API.
Signed-off-by: Chris Wilson
---
drivers/dma-buf/Makefile | 3 +-
drivers/dma-buf/selftests.h | 1 +
drivers/dma-buf/st-dma-fence-chain.c | 713 +++
3 files changed, 716 insertions(+)
For conveniences of callers that just want to use an i915_active to
track a wide array of concurrent timelines, wrap the base i915_active
struct inside a kref. This i915_active will self-destruct after use.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
---
drivers/gp
Userptr causes lockdep to complain when we are using the aliasing-ppgtt
(and ggtt, but for that it is rightfully so to complain about) in that
when we revoke the userptr we take a mutex which we also use to revoke
the mmaps. However, we only revoke mmaps for GGTT bindings and we never
allow userptr
> -Original Message-
> From: Shankar, Uma
> Sent: Thursday, March 26, 2020 6:21 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Shankar, Uma ; Ville Syrjä
> ; Maarten Lankhorst
> ; Kai Vehmanen
> ; Souza; Souza, Jose ;
> Khor, Swee Aun
> Subject: [v3] drm/i915/display: Fix mode private_f
drm-misc-fixes-2020-03-26:
drm-misc-fixes for v5.6:
- SG fixes for prime, radeon and amdgpu.
The following changes since commit b216a8e7908cd750550c0480cf7d2b3a37f06954:
drm/lease: fix WARNING in idr_destroy (2020-03-18 14:42:18 +0100)
are available in the Git repository at:
git://anongit.fr
New i915_pm_lpsp igt solution approach relies on connector specific
debugfs attribute i915_lpsp_info, it exposes whether an output is
capable of driving lpsp and exposes lpsp enablement info.
v2:
- CI fixup.
v3:
- register i915_lpsp_info only for supported connector. [Jani]
- use intel_display_pow
Add connector debugfs attributes for each intel
connector which is getting register.
v2:
- adding connector debugfs for each connector in
intel_connector_register() to fix CI failure for legacy connectors.
Reviewed-by: Jani Nikula
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/displa
Gen11 onwards PG3 is contains functions for pipe B,
external displays, and VGA. It make sense to add
a power well id with name ICL_DISP_PW_3 rather then
TGL_DISP_PW_3, Also PG3 power well id requires to
know if lpsp is enabled.
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel
This series adds i915_lpsp_info connector debugfs.
v3 has fixed some review comments on patch (2/3)
and added RB tag on patch (3/3).
Test-with: 20200326131929.23072-1-anshuman.gu...@intel.com
Anshuman Gupta (3):
drm/i915: Power well id for ICL PG3
drm/i915: Add i915_lpsp_info debugfs
drm/i9
1 - 100 of 150 matches
Mail list logo
