== Series Details ==
Series: drm/i915: Remove the module parameter 'fastboot' (rev2)
URL : https://patchwork.freedesktop.org/series/124255/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13713 -> Patchwork_124255v2
Summary
Signed-off-by: Jouni Högander
---
.../gpu/drm/i915/display/intel_display_params.c | 15 +++
.../gpu/drm/i915/display/intel_display_params.h | 3 +++
drivers/gpu/drm/i915/display/intel_psr.c | 14 +++---
drivers/gpu/drm/i915/i915_params.c| 15
Signed-off-by: Jouni Högander
---
drivers/gpu/drm/i915/display/i9xx_wm.c | 2 +-
drivers/gpu/drm/i915/display/intel_display_params.c | 4
drivers/gpu/drm/i915/display/intel_display_params.h | 3 ++-
drivers/gpu/drm/i915/display/intel_fbc.c| 10 +-
GPU error dump contained all module parameters. If we are moving
display parameters to intel_display_params.[ch] they are not dumped
into GPU error dump. This patch is adding moved display parameters
back to GPU error dump.
Signed-off-by: Jouni Högander
---
Currently all module parameters are handled by i915_param.c/h. This
is a problem for display parameters when Xe driver is used. Add
a mechanism to add parameters specific to the display. This is mainly
copied from i915_[debugfs]_params.[ch]. Parameters are not yet moved. This
is done by subsequent
Currently all module parameters are handled by i915_param.c/h. This
is a problem for display parameters when Xe driver is used.
This patch set adds a mechanism to add parameters specific to the
display. This is mainly copied from existing i915 parameters
implementation with some naming changes
== Series Details ==
Series: drm/i915: Remove the module parameter 'fastboot' (rev2)
URL : https://patchwork.freedesktop.org/series/124255/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: drm/i915/cx0: Only clear/set the Pipe Reset bit of the PHY Lanes Owned
URL : https://patchwork.freedesktop.org/series/124644/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13713 -> Patchwork_124644v1
Hi all,
After merging the drm-misc-fixes tree, today's linux-next build (htmldocs)
produced this warning:
include/uapi/drm/nouveau_drm.h:49: warning: Cannot understand *
@NOUVEAU_GETPARAM_EXEC_PUSH_MAX
on line 49 - I thought it was a doc line
Introduced by commit
d59e75eef52d
Hi all,
After merging the drm-misc tree, today's linux-next build (htmldocs)
produced this warning:
Documentation/gpu/panfrost.rst: WARNING: document isn't included in any toctree
Introduced by commit
f11b0417eec2 ("drm/panfrost: Add fdinfo support GPU load metrics")
--
Cheers,
Stephen
== Series Details ==
Series: drm/i915: Display state checker cleanup (rev2)
URL : https://patchwork.freedesktop.org/series/124616/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13713 -> Patchwork_124616v2
Summary
---
== Series Details ==
Series: drm/i915: Display state checker cleanup (rev2)
URL : https://patchwork.freedesktop.org/series/124616/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: drm/i915: Display state checker cleanup (rev2)
URL : https://patchwork.freedesktop.org/series/124616/
State : warning
== Summary ==
Error: dim checkpatch failed
f16d12e81dfd drm/i915/psr: Unify PSR pre/post plane update hooks
bd2ae6eb9eef drm/i915: Stop clobbering
== Series Details ==
Series: Subject: [PATCH dii-client v6 0/4] drm/i915: Define and use GuC and CTB
TLB invalidation routines
URL : https://patchwork.freedesktop.org/series/124641/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_13713 -> Patchwork_124641v1
== Series Details ==
Series: Subject: [PATCH dii-client v6 0/4] drm/i915: Define and use GuC and CTB
TLB invalidation routines
URL : https://patchwork.freedesktop.org/series/124641/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit
== Series Details ==
Series: Subject: [PATCH dii-client v6 0/4] drm/i915: Define and use GuC and CTB
TLB invalidation routines
URL : https://patchwork.freedesktop.org/series/124641/
State : warning
== Summary ==
Error: dim checkpatch failed
1653f6156104 drm/i915: Add GuC TLB Invalidation pci
== Series Details ==
Series: series starting with [v5,1/4] drm/i915: Add GuC TLB Invalidation pci
tags
URL : https://patchwork.freedesktop.org/series/124636/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_13713 -> Patchwork_124636v1
== Series Details ==
Series: series starting with [v5,1/4] drm/i915: Add GuC TLB Invalidation pci
tags
URL : https://patchwork.freedesktop.org/series/124636/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: series starting with [v5,1/4] drm/i915: Add GuC TLB Invalidation pci
tags
URL : https://patchwork.freedesktop.org/series/124636/
State : warning
== Summary ==
Error: dim checkpatch failed
27e7965d6b55 drm/i915: Add GuC TLB Invalidation pci tags
feb663efcadc
== Series Details ==
Series: powercap: intel_rapl: Don't warn about BIOS locked limits during resume
URL : https://patchwork.freedesktop.org/series/124635/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13712 -> Patchwork_124635v1
Currently, with MFD/pin assignment D, the driver clears the pipe reset bit
of lane 1 which is not owned by display. This causes the display
to block S0iX.
By not clearing this bit for lane 1 and keeping whatever default, S0ix
started to work. This is already what the driver does at the end
of the
== Series Details ==
Series: Patch "drm/i915/gt: Fix reservation address in ggtt_reserve_guc_top"
has been added to the 6.5-stable tree
URL : https://patchwork.freedesktop.org/series/124630/
State : failure
== Summary ==
Error: patch
== Series Details ==
Series: Patch "drm/i915/gt: Fix reservation address in ggtt_reserve_guc_top"
has been added to the 6.1-stable tree
URL : https://patchwork.freedesktop.org/series/124628/
State : failure
== Summary ==
Error: patch
== Series Details ==
Series: drm/dp: switch drm_dp_downstream_*() helpers to struct drm_edid
URL : https://patchwork.freedesktop.org/series/124622/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13712 -> Patchwork_124622v1
== Series Details ==
Series: drm/dp: switch drm_dp_downstream_*() helpers to struct drm_edid
URL : https://patchwork.freedesktop.org/series/124622/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: drm/i915: Display state checker cleanup
URL : https://patchwork.freedesktop.org/series/124616/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_13712 -> Patchwork_124616v1
Summary
---
On 05.10.2023 00:07, Jonathan Cavitt wrote:
> From: Prathap Kumar Valsan
>
snip
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> index 6e22af31513a5..1ee4d4a988398 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> +++
== Series Details ==
Series: drm/i915: Display state checker cleanup
URL : https://patchwork.freedesktop.org/series/124616/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: drm/i915: Display state checker cleanup
URL : https://patchwork.freedesktop.org/series/124616/
State : warning
== Summary ==
Error: dim checkpatch failed
939f6b0c8b59 drm/i915/psr: Unify PSR pre/post plane update hooks
a2b3d7be79dc drm/i915: Stop clobbering old
On 05.10.2023 00:07, Jonathan Cavitt wrote:
> Add pci (device info) flags for if GuC TLB Invalidation is enabled.
nit: maybe avoid using "PCI flag" term here (and in the title) as this
could be little misleading - better stick to "device info flag"
>
> Signed-off-by: Jonathan Cavitt
> ---
>
== Series Details ==
Series: series starting with [1/2] drm/i915: Check lane count when determining
FEC support (rev2)
URL : https://patchwork.freedesktop.org/series/123643/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13712 -> Patchwork_123643v2
In case of GT is suspended or wedged, don't allow submission of new TLB
invalidation request and cancel all pending requests. The TLB entries
will be invalidated either during GuC reload or on system resume.
Signed-off-by: Fei Yang
Signed-off-by: Jonathan Cavitt
CC: John Harrison
---
The GuC firmware had defined the interface for Translation Look-Aside
Buffer (TLB) invalidation. We should use this interface when
invalidating the engine and GuC TLBs.
Add additional functionality to intel_gt_invalidate_tlb, invalidating
the GuC TLBs and falling back to GT invalidation when the
Enable GuC TLB invalidations for MTL. Though more platforms than just
MTL support GuC TLB invalidations, MTL is presently the only platform
that requires it for any purpose, so only enable it there for now to
minimize cross-platform impact.
Signed-off-by: Jonathan Cavitt
---
From: Prathap Kumar Valsan
The GuC firmware had defined the interface for Translation Look-Aside
Buffer (TLB) invalidation. We should use this interface when
invalidating the engine and GuC TLBs.
Add additional functionality to intel_gt_invalidate_tlb, invalidating
the GuC TLBs and falling back
Add pci (device info) tags for if GuC TLB Invalidation is enabled.
Since GuC based TLB invalidation is only strictly necessary for MTL
resently, only enable GuC based TLB invalidations for MTL.
Signed-off-by: Jonathan Cavitt
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
For the gt_tlb live selftest, increase the timeout from 10 ms to 200 ms.
200 ms should be more than enough time, and 10 ms was too aggressive.
Signed-off-by: Jonathan Cavitt
---
drivers/gpu/drm/i915/gt/selftest_tlb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Add pci (device info) flags for if GuC TLB Invalidation is enabled.
Signed-off-by: Jonathan Cavitt
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_device_info.h | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
On Wed, Oct 04, 2023 at 10:58:32PM +0200, Andi Shyti wrote:
> Hi Matt,
>
> > > > > > > The MCR steering semaphore is a shared lock entry between i915
> > > > > > > and various firmware components.
> > > > > > >
> > > > > > > Getting the lock might sinchronize on some shared resources.
> > > > >
On 10/4/2023 13:58, Andi Shyti wrote:
Hi Matt,
The MCR steering semaphore is a shared lock entry between i915
and various firmware components.
Getting the lock might sinchronize on some shared resources.
Sometimes though, it might happen that the firmware forgets to
unlock causing unnecessary
On 10/4/2023 13:09, Andi Shyti wrote:
Hi John,
The MCR steering semaphore is a shared lock entry between i915
and various firmware components.
Getting the lock might sinchronize on some shared resources.
Sometimes though, it might happen that the firmware forgets to
unlock causing unnecessary
== Series Details ==
Series: series starting with [v2,1/6] drm/i915/fbc: Remove ancient 16k plane
stride limit (rev2)
URL : https://patchwork.freedesktop.org/series/124568/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13712 -> Patchwork_124568v2
Hi Matt,
> > > > > > The MCR steering semaphore is a shared lock entry between i915
> > > > > > and various firmware components.
> > > > > >
> > > > > > Getting the lock might sinchronize on some shared resources.
> > > > > > Sometimes though, it might happen that the firmware forgets to
> > > >
Hi John,
> > > > > > The MCR steering semaphore is a shared lock entry between i915
> > > > > > and various firmware components.
> > > > > >
> > > > > > Getting the lock might sinchronize on some shared resources.
> > > > > > Sometimes though, it might happen that the firmware forgets to
> > > >
On Wed, Oct 04, 2023 at 09:35:27PM +0200, Andi Shyti wrote:
> Hi John,
>
> > > > > The MCR steering semaphore is a shared lock entry between i915
> > > > > and various firmware components.
> > > > >
> > > > > Getting the lock might sinchronize on some shared resources.
> > > > > Sometimes
On 10/4/2023 12:35, Andi Shyti wrote:
Hi John,
The MCR steering semaphore is a shared lock entry between i915
and various firmware components.
Getting the lock might sinchronize on some shared resources.
Sometimes though, it might happen that the firmware forgets to
unlock causing unnecessary
> > > > Add pci (device info) tags for if GuC TLB Invalidation is enabled.
> > > > Since GuC based TLB invalidation is only strictly necessary for MTL
> > > > resently, only enable GuC based TLB invalidations for MTL.
> > > >
> > > > Signed-off-by: Jonathan Cavitt
> > > Jani was mentioning that
On Wed, Oct 04, 2023 at 09:24:12PM +0200, Andi Shyti wrote:
> Hi John,
>
> > > > Add pci (device info) tags for if GuC TLB Invalidation is enabled.
> > > > Since GuC based TLB invalidation is only strictly necessary for MTL
> > > > resently, only enable GuC based TLB invalidations for MTL.
> > >
Hi John,
> > > > The MCR steering semaphore is a shared lock entry between i915
> > > > and various firmware components.
> > > >
> > > > Getting the lock might sinchronize on some shared resources.
> > > > Sometimes though, it might happen that the firmware forgets to
> > > > unlock causing
Hi John,
> > > Add pci (device info) tags for if GuC TLB Invalidation is enabled.
> > > Since GuC based TLB invalidation is only strictly necessary for MTL
> > > resently, only enable GuC based TLB invalidations for MTL.
> > >
> > > Signed-off-by: Jonathan Cavitt
> > Jani was mentioning that
On 10/4/2023 07:08, Andi Shyti wrote:
Hi Tvrtko,
The MCR steering semaphore is a shared lock entry between i915
and various firmware components.
Getting the lock might sinchronize on some shared resources.
Sometimes though, it might happen that the firmware forgets to
unlock causing
On 10/4/2023 12:03, Andi Shyti wrote:
Hi Jonathan,
On Wed, Oct 04, 2023 at 11:36:22AM -0700, Jonathan Cavitt wrote:
Add pci (device info) tags for if GuC TLB Invalidation is enabled.
Since GuC based TLB invalidation is only strictly necessary for MTL
resently, only enable GuC based TLB
Why is there no cover letter for this patch series?
It is at v5 but there is no history of what has changed from one version
to the next. That makes it much harder to review.
John.
On 10/4/2023 11:36, Jonathan Cavitt wrote:
Add pci (device info) tags for if GuC TLB Invalidation is enabled.
Hi Jonathan,
On Wed, Oct 04, 2023 at 11:36:22AM -0700, Jonathan Cavitt wrote:
> Add pci (device info) tags for if GuC TLB Invalidation is enabled.
> Since GuC based TLB invalidation is only strictly necessary for MTL
> resently, only enable GuC based TLB invalidations for MTL.
>
> Signed-off-by:
On Wed, Oct 04, 2023 at 06:45:22PM +, Pandruvada, Srinivas wrote:
> On Wed, 2023-10-04 at 21:34 +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Restore enough of the original behaviour to stop spamming
> > dmesg with warnings about BIOS locked limits when trying
> > to restore
== Series Details ==
Series: drm/i915: Reduce MCR lock surface (rev2)
URL : https://patchwork.freedesktop.org/series/124604/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13709_full -> Patchwork_124604v2_full
Summary
In case of GT is suspended or wedged, don't allow submission of new TLB
invalidation request and cancel all pending requests. The TLB entries
will be invalidated either during GuC reload or on system resume.
Signed-off-by: Fei Yang
Signed-off-by: Jonathan Cavitt
CC: John Harrison
---
From: Prathap Kumar Valsan
The GuC firmware had defined the interface for Translation Look-Aside
Buffer (TLB) invalidation. We should use this interface when
invalidating the engine and GuC TLBs.
Add additional functionality to intel_gt_invalidate_tlb, invalidating
the GuC TLBs and falling back
Add pci (device info) tags for if GuC TLB Invalidation is enabled.
Since GuC based TLB invalidation is only strictly necessary for MTL
resently, only enable GuC based TLB invalidations for MTL.
Signed-off-by: Jonathan Cavitt
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
For the gt_tlb live selftest, increase the timeout from 10 ms to 200 ms.
200 ms should be more than enough time, and 10 ms was too aggressive.
Signed-off-by: Jonathan Cavitt
---
drivers/gpu/drm/i915/gt/selftest_tlb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Wed, 2023-10-04 at 21:34 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Restore enough of the original behaviour to stop spamming
> dmesg with warnings about BIOS locked limits when trying
> to restore them during resume.
>
> This still doesn't 100% match the original behaviour
> as
6.5-stable review patch. If anyone has any objections, please let me know.
--
From: Javier Pello
commit b7599d241778d0b10cdf7a5c755aa7db9b83250c upstream.
There is an assertion in ggtt_reserve_guc_top that the global GTT
is of size at least GUC_GGTT_TOP, which is not the case
From: Ville Syrjälä
Restore enough of the original behaviour to stop spamming
dmesg with warnings about BIOS locked limits when trying
to restore them during resume.
This still doesn't 100% match the original behaviour
as we no longer attempt to blindly restore the BIOS locked
limits. No idea
6.1-stable review patch. If anyone has any objections, please let me know.
--
From: Javier Pello
commit b7599d241778d0b10cdf7a5c755aa7db9b83250c upstream.
There is an assertion in ggtt_reserve_guc_top that the global GTT
is of size at least GUC_GGTT_TOP, which is not the case
On Thu, 2023-09-28 at 13:46 +0100, Tvrtko Ursulin wrote:
> On 27/09/2023 17:36, Teres Alexis, Alan Previn wrote:
> > Thanks for taking the time to review this Tvrtko, replies inline below.
alan:snip
> > >
> > > Main concern is that we need to be sure there are no possible
> > > ill-effects, like
On Wed, Oct 04, 2023 at 07:57:08PM +0300, Jani Nikula wrote:
> On Wed, 04 Oct 2023, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > There is never any reason to pass in both the crtc and its state
> > as one can always dig out the crtc from its state.
>
> I'm wondering whether we shouldn't
The following changes since commit 5105ff4b9f43ba08d0a22260d670120e53c4b667:
Merge branch 'mlimonci/upstream-packaging' into 'main' (2023-10-04 12:35:17
+)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-firmware xe_pvc_guc_70.9.1
for you to fetch changes
On Wed, Oct 04, 2023 at 07:21:49PM +0300, Jani Nikula wrote:
> Prefer struct drm_edid where possible. With limited users for the
> drm_dp_downstream_*() helpers, this is fairly straightforward.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
>
This is a note to let you know that I've just added the patch titled
drm/i915/gt: Fix reservation address in ggtt_reserve_guc_top
to the 6.5-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch
This is a note to let you know that I've just added the patch titled
drm/i915/gt: Fix reservation address in ggtt_reserve_guc_top
to the 6.1-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch
I will try to ping Zhenyu to pick it up from GVT-g.
Thanks,
Zhi.
-Original Message-
From: Nikula, Jani
Sent: Wednesday, October 4, 2023 7:33 PM
To: Wang, Zhi A ; intel-gvt-...@lists.freedesktop.org;
Zhenyu Wang
Cc: intel-gfx@lists.freedesktop.org
Subject: RE: [PATCH 1/4]
On Wed, 04 Oct 2023, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The biggest thing here is changing the state checker to use
> a dedicated crtc state (instead of clobbering the old state),
> the rest is all polish.
A bikeshed on one commit, can be ignored, the series is
Reviewed-by: Jani
On Wed, 04 Oct 2023, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> There is never any reason to pass in both the crtc and its state
> as one can always dig out the crtc from its state.
I'm wondering whether we shouldn't just always pass
struct intel_atomic_state *state, struct intel_crtc
On Wed, 2023-10-04 at 06:34 +, Gupta, Anshuman wrote:
>
> > -Original Message-
> > From: Teres Alexis, Alan Previn > @@ -289,6 +289,13 @@ int intel_gt_resume(struct intel_gt *gt)
> >
> > static void wait_for_suspend(struct intel_gt *gt) {
> > + /*
> > +* On rare occasions,
On Wed, 04 Oct 2023, "Wang, Zhi A" wrote:
> Singed-off-by: Zhi Wang
Mmh, sorry, what does that mean here? Are you picking them up via gvt?
BR,
Jani.
>
> Thanks,
> Zhi.
>
> -Original Message-
> From: Nikula, Jani
> Sent: Wednesday, October 4, 2023 3:54 PM
> To:
Prefer struct drm_edid where possible. With limited users for the
drm_dp_downstream_*() helpers, this is fairly straightforward.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/display/drm_dp_helper.c | 39 ++-
.../drm/i915/display/intel_display_debugfs.c | 3 +-
Hi Rodrigo,
On 10/4/2023 4:37 PM, Rodrigo Vivi wrote:
On Wed, Oct 04, 2023 at 03:54:59PM +0200, Nirmoy Das wrote:
Hi Rodrigo,
On 10/4/2023 2:44 PM, Rodrigo Vivi wrote:
On Wed, Oct 04, 2023 at 02:04:07PM +0200, Nirmoy Das wrote:
Take the mcr lock only when driver needs to write into a mcr
Singed-off-by: Zhi Wang
Thanks,
Zhi.
-Original Message-
From: Nikula, Jani
Sent: Wednesday, October 4, 2023 3:54 PM
To: intel-gvt-...@lists.freedesktop.org; Zhenyu Wang ;
Wang, Zhi A
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/4] drm/i915/gvt: remove unused to_gvt()
From: Ville Syrjälä
Switch over to the modern variable naming in the state checker.
Ie. rename the pipe_config stuff to crtc_state.
Also make it clear which is the "software state" (ie. what the
current state should be) vs. "hardware state" (ie. what the
currnet state really is).
From: Ville Syrjälä
Switch the state checker over to using the new 'i915' variable
name insteda of the old 'dev_priv'.
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_modeset_verify.c | 34 +--
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git
From: Ville Syrjälä
We're passing in a totally random mismash of things into the state
checker. Clean it up to pass in the minimum needed.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 4 ++--
.../drm/i915/display/intel_modeset_verify.c | 24
From: Ville Syrjälä
Mark the remaining crtc states used by the state checker as const.
There is no reason to ever mutate them here.
Signed-off-by: Ville Syrjälä
---
.../gpu/drm/i915/display/intel_modeset_verify.c| 14 +++---
.../gpu/drm/i915/display/intel_modeset_verify.h| 4
From: Ville Syrjälä
Passing in the atomic state + crtc state is a bit weird. The latter
can be just the crtc (which is the normal calling convention used
in a lot of other places).
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cx0_phy.c| 5 +++--
From: Ville Syrjälä
State checkers should never modify the crtc states, so make
them const.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cx0_phy.c | 4 ++--
drivers/gpu/drm/i915/display/intel_cx0_phy.h | 2 +-
drivers/gpu/drm/i915/display/intel_snps_phy.c | 4 ++--
From: Ville Syrjälä
There is never any reason to pass in both the crtc and its state
as one can always dig out the crtc from its state.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_modeset_verify.c | 2 +-
drivers/gpu/drm/i915/display/skl_watermark.c| 4 ++--
From: Ville Syrjälä
The skl+ wm state checker has no reason to modify the crtc state,
so make it const.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/skl_watermark.c | 2 +-
drivers/gpu/drm/i915/display/skl_watermark.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
From: Ville Syrjälä
The DPLL state checker should not be modifying the crtc states,
so make the const.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 6 +++---
drivers/gpu/drm/i915/display/intel_dpll_mgr.h | 4 ++--
2 files changed, 5 insertions(+), 5
From: Ville Syrjälä
Make life simpler by just passing in the atomic state + crtc
instead of plumbing in all kinds of crtc states.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 14 +-
drivers/gpu/drm/i915/display/intel_dpll_mgr.h | 7
From: Ville Syrjälä
The state checker overwrites the old crtc state with the
current hardware state. While that does save a kmalloc() it seems
rather dubious as there might still be something that we need
in the old crtc state.
Stop doing that and just allocate a temporary state for the state
From: Ville Syrjälä
intel_psr_pre_plane_update() operates on a per-crtc level, whereas
intel_psr_post_plane_update() operates on the whole atomic commit,
for no real reason that I can see. Adjust intel_psr_post_plane_update()
to match the intel_psr_pre_plane_update() approach.
Signed-off-by:
From: Ville Syrjälä
The biggest thing here is changing the state checker to use
a dedicated crtc state (instead of clobbering the old state),
the rest is all polish.
Ville Syrjälä (12):
drm/i915/psr: Unify PSR pre/post plane update hooks
drm/i915: Stop clobbering old crtc state during state
On Sat, Sep 30, 2023 at 01:24:00AM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/dp_mst: Make sure pbn_div is up-to-date after sink reconnect
> URL : https://patchwork.freedesktop.org/series/124462/
> State : success
Thanks for the review, patchset is pushed to
From: Ville Syrjälä
The current check just asserts that we need FEC to use DSC
with (non-eDP) DP-SST. But MST also needs FEC for DSC. Just
check for !eDP instead to cover all the cases correctly.
v2: DP2/UHBR always uses FEC even though we don't flag it (Jani)
Signed-off-by: Ville Syrjälä
---
On Mon, 02 Oct 2023, Andi Shyti wrote:
> Hi Jani,
>
> adding a few folks in Cc for some extra eyes on this series.
Thanks for the reviews and acks, pushed to drm-intel-next.
drm-intel-next instead of drm-intel-gt-next because of the changes in
i915_drv.h, and it's easier to sync from din to
On Wed, Oct 04, 2023 at 09:25:40AM +0100, Tvrtko Ursulin wrote:
>
> On 03/10/2023 22:08, Jonathan Cavitt wrote:
> > Increase the timeout MCR waits for the steering semaphore
> > in intel_gt_mcr_lock by a factor of 10.
>
> Ideally you mention why in the commit message, with some appropriate level
On Wed, Oct 04, 2023 at 03:54:59PM +0200, Nirmoy Das wrote:
> Hi Rodrigo,
>
> On 10/4/2023 2:44 PM, Rodrigo Vivi wrote:
> > On Wed, Oct 04, 2023 at 02:04:07PM +0200, Nirmoy Das wrote:
> > > Take the mcr lock only when driver needs to write into a mcr based
> > > tlb based registers.
> > >
> > >
On 03/10/2023 22:01, Jonathan Cavitt wrote:
In case of GT is suspended or wedged, don't allow submission of new TLB
invalidation request and cancel all pending requests. The TLB entries
will be invalidated either during GuC reload or on system resume.
Signed-off-by: Fei Yang
Signed-off-by:
== Series Details ==
Series: drm/i915/gt: Do not treat MCR locking timeouts as errors
URL : https://patchwork.freedesktop.org/series/124599/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_13708_full -> Patchwork_124599v1_full
Am 04.10.23 um 01:03 schrieb Andi Shyti:
From: Chris Wilson
Enforce that an mmap of a dmabuf is always using MAP_SHARED so that all
access (both read and writes) using the device memory and not a local
copy-on-write page in system memory.
As much as I would like to do this I fear that this
On 03/10/2023 22:01, Jonathan Cavitt wrote:
From: Prathap Kumar Valsan
The GuC firmware had defined the interface for Translation Look-Aside
Buffer (TLB) invalidation. We should use this interface when
invalidating the engine and GuC TLBs.
Add additional functionality to
1 - 100 of 144 matches
Mail list logo
