> -Original Message-
> From: Kandpal, Suraj
> Sent: Thursday, February 1, 2024 2:22 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Borah, Chaitanya Kumar ; Kandpal,
> Suraj
> Subject: [PATCH 2/2] drm/i915/lnl: Program PKGC_LATENCY register
>
> Program the PKGC_LATENCY register with
After we move the cursor fb unpin to a vblank work, we encounter
race conditions between the vblank work and the atomic clean up
work leading to dump stacks[1]. Let's serialize the clean up
to avoid theses races.
[1]
[ 278.748767] Workqueue: events_highpri intel_atomic_cleanup_work [i915]
Now that cursor plane fb unpinning can be deferred to vblank work
access the fb object only when vblank unpin worker is not scheduled.
v2: - Remove misleading error log
- Change condition for accessing fb object
Signed-off-by: Chaitanya Kumar Borah
---
The plane destroy hook can be called asynchronously even when vblank
worker responsible for unpinning the cursor fb is scheduled. Since
the vblank worker destroys the plane state, do not destroy the plane
state if it is scheduled.
Signed-off-by: Chaitanya Kumar Borah
---
From: Maarten Lankhorst
In case of legacy cursor update, the cursor VMA needs to be unpinned
only after vblank. This exceeds the lifetime of the whole atomic commit.
Any trick I attempted to keep the atomic commit alive didn't work, as
drm_atomic_helper_setup_commit() force throttles on any old
From: Ville Syrjälä
The cursor hardware only does sync updates, and thus the hardware
will be scanning out from the old fb until the next start of vblank.
So in order to make the legacy cursor fastpath actually safe we
should not unpin the old fb until we're sure the hardware has
ceased
From: Maarten Lankhorst
In some cases we want to flush all vblank work, right before vblank_off
for example. Add a simple function to make this possible.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_vblank_work.c | 22 ++
include/drm/drm_vblank_work.h | 2
This series is based on top of [1] floated by Maarten.
To fix regressions seen in CI, following changes were made on top of the
original series.
1. add a check in the plane state destroy hook to not move forward if the
vblank worker is scheduled.
2. add checks before accessing frame buffer
== Series Details ==
Series: Cursor Fault Fixes (rev2)
URL : https://patchwork.freedesktop.org/series/129517/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_14217 -> Patchwork_129517v2
Summary
---
**FAILURE**
== Series Details ==
Series: Cursor Fault Fixes (rev2)
URL : https://patchwork.freedesktop.org/series/129517/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+./arch/x86/include/asm/bitops.h:116:1: warning:
== Series Details ==
Series: Cursor Fault Fixes (rev2)
URL : https://patchwork.freedesktop.org/series/129517/
State : warning
== Summary ==
Error: dim checkpatch failed
c3e0c5453914 drm: Add drm_vblank_work_flush_all().
-:33: WARNING:WAITQUEUE_ACTIVE: waitqueue_active without comment
#33:
> -Original Message-
> From: Hogander, Jouni
> Sent: Friday, February 2, 2024 1:50 PM
> To: Manna, Animesh ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [PATCH v3 06/21] drm/i915/psr: Check possible errors for panel
> replay as well
>
> On Fri, 2024-02-02 at 08:10 +, Manna,
> -Original Message-
> From: Hogander, Jouni
> Sent: Friday, February 2, 2024 1:17 PM
> To: Manna, Animesh ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [PATCH v3 04/21] drm/i915/psr: Rename intel_psr_enabled
>
> On Fri, 2024-02-02 at 07:34 +, Manna, Animesh wrote:
> >
> >
>
> -Original Message-
> From: Hogander, Jouni
> Sent: Friday, January 19, 2024 3:40 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Manna, Animesh ; Hogander, Jouni
>
> Subject: [PATCH v3 19/21] drm/i915/psr: Update PSR module parameter
> descriptions
>
> We are re-using PSR module
> -Original Message-
> From: Hogander, Jouni
> Sent: Friday, January 19, 2024 3:40 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Manna, Animesh ; Hogander, Jouni
>
> Subject: [PATCH v3 16/21] drm/i915/psr: Ensure early transport is not
> enabled for panel replay
>
> Early transport
This series is based on top of [1] floated by Maarten.
To fix regressions seen in CI, following changes were made on top of the
original series.
1. add a check in the plane state destroy hook to not move forward if the
vblank worker is scheduled.
2. add checks before accessing frame buffer
After we move the cursor fb unpin to a vblank work, we encounter
race conditions between the vblank work and the atomic clean up
work leading to dump stacks[1]. Let's serialize the clean up
to avoid theses races.
[1]
[ 278.748767] Workqueue: events_highpri intel_atomic_cleanup_work [i915]
From: Ville Syrjälä
The cursor hardware only does sync updates, and thus the hardware
will be scanning out from the old fb until the next start of vblank.
So in order to make the legacy cursor fastpath actually safe we
should not unpin the old fb until we're sure the hardware has
ceased
The plane destroy hook can be called asynchronously even when vblank
worker responsible for unpinning the cursor fb is scheduled. Since
the vblank worker destroys the plane state, do not destroy the plane
state if it is scheduled.
Signed-off-by: Chaitanya Kumar Borah
---
Now that cursor plane fb unpinning can be deferred to vblank work
check if plane state and corresponding fb pointers are still valid
before cleanup.
Signed-off-by: Chaitanya Kumar Borah
---
drivers/gpu/drm/i915/display/intel_atomic_plane.c | 8 +++-
1 file changed, 7 insertions(+), 1
From: Maarten Lankhorst
In some cases we want to flush all vblank work, right before vblank_off
for example. Add a simple function to make this possible.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_vblank_work.c | 22 ++
include/drm/drm_vblank_work.h | 2
From: Maarten Lankhorst
In case of legacy cursor update, the cursor VMA needs to be unpinned
only after vblank. This exceeds the lifetime of the whole atomic commit.
Any trick I attempted to keep the atomic commit alive didn't work, as
drm_atomic_helper_setup_commit() force throttles on any old
On 2024.02.01 16:44:05 +0200, Joonas Lahtinen wrote:
> Hi Zhenyu,
>
> I'm getting the following:
>
> dim: ff833b32ccc4 ("drm/i915: Replace dead 01.org link"): mandatory review
> missing.
> dim: ERROR: issues in commits detected, aborting
>
> Can you fix the commit?
>
Sorry, I missed to add
== Series Details ==
Series: Cursor Fault Fixes
URL : https://patchwork.freedesktop.org/series/129517/
State : failure
== Summary ==
Error: make failed
CALLscripts/checksyscalls.sh
DESCEND objtool
INSTALL libsubcmd_headers
CC [M] drivers/gpu/drm/i915/display/intel_display.o
From: Maarten Lankhorst
In case of legacy cursor update, the cursor VMA needs to be unpinned
only after vblank. This exceeds the lifetime of the whole atomic commit.
Any trick I attempted to keep the atomic commit alive didn't work, as
drm_atomic_helper_setup_commit() force throttles on any old
After we move the cursor fb unpin to a vblank work, we encounter
race conditions between the vblank work and the atomic clean up
work leading to dump stacks[1]. Let's serialize the clean up
to avoid theses races.
[1]
[ 278.748767] Workqueue: events_highpri intel_atomic_cleanup_work [i915]
Now that cursor plane fb unpinning can be deferred to vblank work
check if plane state and corresponding fb pointers are still valid
before cleanup.
Signed-off-by: Chaitanya Kumar Borah
---
drivers/gpu/drm/i915/display/intel_atomic_plane.c | 8 +++-
1 file changed, 7 insertions(+), 1
The plane destroy hook can be called asynchronously even when vblank
worker responsible for unpinning the cursor fb is scheduled. Since
the vblank worker destroys the plane state, do not destroy the plane
state if it is scheduled.
Signed-off-by: Chaitanya Kumar Borah
---
This series is based on top of [1] floated by Maarten.
To fix, regressions seen in CI following changes were made on top of the
original series.
1. add a check in the plane state destroy hook to not move forward if the
vblank worker is scheduled.
2. add checks before accessing frame buffer
From: Ville Syrjälä
The cursor hardware only does sync updates, and thus the hardware
will be scanning out from the old fb until the next start of vblank.
So in order to make the legacy cursor fastpath actually safe we
should not unpin the old fb until we're sure the hardware has
ceased
Hello Maarten,
> -Original Message-
> From: Intel-gfx On Behalf Of
> Maarten Lankhorst
> Sent: Wednesday, January 31, 2024 5:40 PM
> To: intel...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org
> Subject: [CI 2/3] drm/i915: Use vblank worker to unpin old legacy cursor fb
> safely
== Series Details ==
Series: HDCP Type1 MST fixes
URL : https://patchwork.freedesktop.org/series/129512/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_14216 -> Patchwork_129512v1
Summary
---
**SUCCESS**
No
== Series Details ==
Series: HDCP Type1 MST fixes
URL : https://patchwork.freedesktop.org/series/129512/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+./arch/x86/include/asm/bitops.h:116:1: warning:
Currently intel_hdcp is not being extracted from primary connector
this patch fixes that.
Fixes: 524240b231ea ("drm/i915/hdcp: Propagate aux info in DP HDCP functions")
Signed-off-by: Suraj Kandpal
Reviewed-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 7 +--
1 file
We see some monitors and docks report incorrect hdcp version
and capability in first few reads so we read rx_caps three times
before we conclude the monitor's or docks HDCP capability
--v2
-Add comment to justify the 3 time read loop for hdcp capability[Ankit]
Signed-off-by: Suraj Kandpal
Allocate stream id after HDCP AKE stage and not before so that it
can also be done during link integrity check.
Right now for MST scenarios LIC fails after hdcp enablement for this
reason.
Signed-off-by: Suraj Kandpal
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 115 ++
1
Save acquire_ctx in intel_hdcp so that it can be used later
for locking to get vcpi id without need to propate intel_atomic_state.
Furthermore it can be called from work_struct where deriving
intel_atomic_state is not possible.
Signed-off-by: Suraj Kandpal
---
Now that we have moved back to direct reads the additional timing
is not required hence this can be removed.
--v2
-Add Fixes tag [Ankit]
Fixes: 3974f9c17bb9 ("drm/i915/hdcp: Adjust timeout for read in DPMST Scenario")
Signed-off-by: Suraj Kandpal
Reviewed-by: Ankit Nautiyal
---
Currently we are only checking capability of remote device and not
immediate downstream device but during capability check we need are
concerned with only the HDCP capability of downstream device.
During i915_display_info reporting we need HDCP Capability for both
the monitors and downstream
Create a remote HDCP capability shim function which can read the
remote monitor HDCP capability when in MST configuration.
--v2
-Add an assertion to make sure only mst encoder call this remote_cap
function [Ankit]
Signed-off-by: Suraj Kandpal
---
.../drm/i915/display/intel_display_types.h|
Even for MST scenarios we need to do direct reads only on the
immediate downstream device the rest of the authentication is taken
care by that device. Remote reads will only be used to check
capability of the monitors in MST topology.
--v2
-Add fixes tag [Ankit]
-Derive aux where needed rather
Break intel_dp_hdcp2_capable so that the common the code can be
reused for the remote capability check.
Signed-off-by: Suraj Kandpal
Reviewed-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git
Pass drm_dp_aux to intel_dp_hdcp_read_bcaps function
so as to aid in reading the bcaps for the remote monitor
later on.
Signed-off-by: Suraj Kandpal
Reviewed-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
Move checks on the source side for HDCP2.2 into its own function
so that they can be used in the HDCP remote capability check
function.
Signed-off-by: Suraj Kandpal
Reviewed-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 20 +---
1 file changed, 17
We were seeing a blank screen whenever Type1 content was played.
This was due to extra timing which was taken as we had moved to
remote read and writes previously for MST scenario, which in turn
was done as we were not able to do direct read and writes to the
immediate downstream device.
The
== Series Details ==
Series: HDCP Type1 MST fixes
URL : https://patchwork.freedesktop.org/series/129509/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_14216 -> Patchwork_129509v1
Summary
---
**FAILURE**
Serious
== Series Details ==
Series: HDCP Type1 MST fixes
URL : https://patchwork.freedesktop.org/series/129509/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+./arch/x86/include/asm/bitops.h:116:1: warning:
47 matches
Mail list logo
