== 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: 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
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:
>
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
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
---
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
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
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
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ä)
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
---
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
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
== 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
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ä
> -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
== 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
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
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
== 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: 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:
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
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
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
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
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
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
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
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
---
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.
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:
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
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
== 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**
== 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 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/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
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
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
== 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
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
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
== 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: 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
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
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
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
== 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
== 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
== 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]
== Series Details ==
Series: drm/i915/perf: Do not clear pollin for small user read buffers (rev2)
URL : https://patchwork.freedesktop.org/series/75085/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8190_full -> Patchwork_17092_full
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.
== 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
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
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
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
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
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
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
---
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
== 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
== 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
---
== 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
== 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
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
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
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: 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"
> -Original Message-
> From: Khor, Swee Aun
> Sent: Tuesday, March 24, 2020 11:26 AM
> To: Ville Syrjälä ; Shankar, Uma
>
> Cc: Souza, Jose ; intel-gfx@lists.freedesktop.org
> Subject: RE: [Intel-gfx] [PATCH] drm/i915/display: Trigger Modeset at boot
> for audio
> codec init
>
> Git
On Thu, 26 Mar 2020, Masahiro Yamada wrote:
> CONFIG_AS_MOVNTDQA was introduced by commit 0b1de5d58e19 ("drm/i915:
> Use SSE4.1 movntdqa to accelerate reads from WC memory").
>
> We raise the minimal supported binutils version from time to time.
> The last bump was commit 1fb12b35e5ff ("kbuild:
== Series Details ==
Series: drm/i915/display: Remove useless but deadly local
URL : https://patchwork.freedesktop.org/series/75109/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8190 -> Patchwork_17094
Summary
---
On 25/03/2020 23:48, Chris Wilson wrote:
We've migrated all the heavy users over to the intel_gt, and can finally
drop the last few users and with that the mirror in dev_priv->engine[].
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Andi Shyti
---
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 if display
is connected at boot. Initial discussion on this issue has
== Series Details ==
Series: drm/i915/display: Fix mode private_flags comparison at atomic_check
URL : https://patchwork.freedesktop.org/series/75106/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8190 -> Patchwork_17093
On Thu, 26 Mar 2020, Chris Wilson wrote:
> Beware dereferencing the NULL pointer prior to checking for its
> existence.
Huh, I don't see the failure mode. Please enlighten me.
BR,
Jani.
>
> Fixes: 419190429cd1 ("drm/i915/hdmi: use struct drm_device based logging")
> Signed-off-by: Chris Wilson
== Series Details ==
Series: drm/i915/display: Fix mode private_flags comparison at atomic_check
URL : https://patchwork.freedesktop.org/series/75106/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8190_full -> Patchwork_17093_full
Beware dereferencing the NULL pointer prior to checking for its
existence.
Fixes: 419190429cd1 ("drm/i915/hdmi: use struct drm_device based logging")
Signed-off-by: Chris Wilson
Cc: Wambui Karuga
Cc: Jani Nikula
Cc: "Ville Syrjälä"
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 5 ++---
1
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 exact user buffer size is not
known. Blocking user space in poll can lead
* Masahiro Yamada wrote:
> > LGTM. I've got these four from Jason A. Donenfeld queued up in
> > tip:WIP.x86/asm:
> >
> > bd5b1283e41c: ("crypto: Curve25519 - do not pollute dispatcher based on
> > assembler")
> > 829f32d78588: ("crypto: X86 - rework configuration, based on Kconfig")
> >
* Jason A. Donenfeld wrote:
> Very little has changed from last time, and this whole series still
> looks good to me. I think I already ack'd most packages, but in case
> it helps:
>
> Reviewed-by: Jason A. Donenfeld
Acked-by: Ingo Molnar
> Since this touches a lot of stuff, it might be
== Series Details ==
Series: drm/i915/display: Remove useless but deadly local
URL : https://patchwork.freedesktop.org/series/75109/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8190_full -> Patchwork_17094_full
Summary
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
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 if display
is connected at boot. Initial discussion on this issue has
> -Original Message-
> From: Maarten Lankhorst
> Sent: Thursday, March 26, 2020 5:38 PM
> To: Shankar, Uma ; intel-gfx@lists.freedesktop.org
> Cc: Ville Syrjä ; Kai Vehmanen
> ; Souza, Jose ; Khor, Swee
> Aun
> Subject: Re: [v2] drm/i915/display: Fix mode private_flags comparison at
>
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 if display
is connected at boot. Initial discussion on this issue has
On Thu, 26 Mar 2020, Chris Wilson wrote:
> Beware dereferencing the NULL pointer prior to checking for its
> existence.
Okay, so the crt code calls ddi functions, and enc_to_dig_port() will
return NULL. Backtrace for posterity below, copy-pasted from logs Chris
pointed me at.
I think
Op 26-03-2020 om 08:49 schreef Uma Shankar:
> 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 if display
> is
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
---
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
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
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
Make sure vma_lock is not used as inner lock when kernel context is used,
and add ww handling where appropriate.
Signed-off-by: Maarten Lankhorst
---
.../i915/gem/selftests/i915_gem_coherency.c | 26 ++--
.../drm/i915/gem/selftests/i915_gem_mman.c| 41 ++-
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 b39c24dae64e..e35e8d0b6938
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
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
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
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
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
1 - 100 of 141 matches
Mail list logo
