On 04/10/2023 04:40, Vivaik Balasubrawmanian wrote:
Due to a bug in GuC firmware, Mesa can't enable by default the usage of
async compute engines feature in DG2 and newer. A new GuC firmware fixed the
issue but
until now there was no way for Mesa to know if KMD was running with the fixed
GuC
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 of detail depending on the situation.
+Matt for MCR stuff.
Regards,
Hi Vivaik,
On Tue, Oct 03, 2023 at 08:40:12PM -0700, Vivaik Balasubrawmanian wrote:
> Due to a bug in GuC firmware, Mesa can't enable by default the usage of
> async compute engines feature in DG2 and newer. A new GuC firmware fixed the
> issue but
> until now there was no way for Mesa to know
On 03/10/2023 17:41, Andi Shyti wrote:
Hi,
[...]
+static void guc_ggtt_invalidate(struct i915_ggtt *ggtt)
+{
+ struct drm_i915_private *i915 = ggtt->vm.i915;
+ struct intel_gt *gt;
+
+ if (!IS_GEN9_LP(i915) && GRAPHICS_VER(i915) < 11)
+
== Series Details ==
Series: series starting with [v4,1/3] drm/i915: Add GuC TLB Invalidation pci
tags (rev2)
URL : https://patchwork.freedesktop.org/series/124575/
State : warning
== Summary ==
Error: dim checkpatch failed
d3517ddb590f drm/i915: Add GuC TLB Invalidation pci tags
== Series Details ==
Series: series starting with [v4,1/3] drm/i915: Add GuC TLB Invalidation pci
tags (rev2)
URL : https://patchwork.freedesktop.org/series/124575/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked
On Tue, 03 Oct 2023, John Harrison wrote:
> On 10/3/2023 08:59, Andi Shyti wrote:
>> Hi Jani,
>>
Consider multi-gt support when cancelling all tlb invalidations on
suspend, and when submitting tlb invalidations on resume.
Suggested-by: Tvrtko Ursulin
Signed-off-by: Fei
== Series Details ==
Series: series starting with [v4,1/3] drm/i915: Add GuC TLB Invalidation pci
tags (rev2)
URL : https://patchwork.freedesktop.org/series/124575/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_13708 -> Patchwork_124575v2
> -Original Message-
> From: Intel-gfx On Behalf Of Uma
> Shankar
> Sent: Friday, September 29, 2023 1:13 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Nikula, Jani
> Subject: [Intel-gfx] [v4] drm/i915/display: Created exclusive version of vga
> decode setup
>
> Current vga arbiter
> -Original Message-
> From: Manna, Animesh
> Sent: Thursday, September 21, 2023 11:44 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org; Nikula, Jani ;
> Hogander, Jouni ; Murthy, Arun R
> ; Manna, Animesh
> Subject: [PATCH v6 1/6] drm/panelreplay: dpcd
> -Original Message-
> From: Manna, Animesh
> Sent: Thursday, September 21, 2023 11:44 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org; Nikula, Jani ;
> Hogander, Jouni ; Murthy, Arun R
>
> Subject: [PATCH v6 2/6] drm/i915/psr: Move psr specific dpcd init
On Tue, 03 Oct 2023, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Start to clean up the mess around DPLL IDs a bit by removing
> the nasty assumption that the index of the DPLL in the
> arrays matches its ID. Fortunately we did have a WARN
> i nthere to cathc mistakes, but better to not has
> -Original Message-
> From: Teres Alexis, Alan Previn
> Sent: Wednesday, September 27, 2023 12:35 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Teres Alexis, Alan Previn ; dri-
> de...@lists.freedesktop.org; Vivi, Rodrigo ; Ceraolo
> Spurio, Daniele ; Harrison, John C
> ; Anshuman
On 03/10/2023 21:23, John Harrison wrote:
On 10/3/2023 03:28, Tvrtko Ursulin wrote:
On 02/10/2023 18:24, 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
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 noise in the driver which keeps doing
what was
On 03.10.23 09:32, Tvrtko Ursulin wrote:
> On 29/09/2023 12:00, Tvrtko Ursulin wrote:
>> [...]
>> Thanks again!
>>
>> Reviewed-by: Tvrtko Ursulin
>
> Patches pushed to drm-intel-gt-next.
>
Thanks, Tvrtko!
I guess this implies no backport of the first patch to older kernels, as
it affects
Hello Matthew Brost,
This is a semi-automatic email about new static checker warnings.
The patch 22916bad07a5: "drm/i915: Move submission tasklet to
i915_sched_engine" from Jun 17, 2021, leads to the following Smatch
complaint:
drivers/gpu/drm/i915/gt/intel_execlists_submission.c:3659
On Tue, 2023-10-03 at 22:42 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Carve up pixel_format_is_valid() into per-platform variants to
> make it easier to see what limits are actually being imposed.
>
> Note that the XRGB1555 can be dropped from the g4x+ variant
> since the plane no
On 04/10/2023 10:43, Andi Shyti wrote:
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 noise
Hello Ville Syrjälä,
The patch f83b94d23770: "drm/i915/dsb: Use DEwake to combat PkgC
latency" from Jun 6, 2023 (linux-next), leads to the following Smatch
static checker warning:
drivers/gpu/drm/i915/display/intel_dsb.c:363 _intel_dsb_commit()
warn: always true condition
Take the mcr lock only when driver needs to write into a mcr based
tlb based registers.
To prevent GT reset interference, employ gt->reset.mutex instead, since
intel_gt_mcr_multicast_write relies on gt->uncore->lock not being held.
Signed-off-by: Nirmoy Das
---
On Mon, Oct 2, 2023 at 8:59 AM Gustavo Sousa wrote:
>
> The following changes since commit 8b855f3797e6b1d207b7a2b8dae0e9913f907e5b:
>
> Merge branch 'main' into 'main' (2023-09-26 18:31:16 +)
>
> are available in the Git repository at:
>
> git://anongit.freedesktop.org/drm/drm-firmware
== Series Details ==
Series: drm/i915/display: Reset message bus after each read/write operation
URL : https://patchwork.freedesktop.org/series/124602/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13709 -> Patchwork_124602v1
== Series Details ==
Series: drm/i915/gt: Do not treat MCR locking timeouts as errors
URL : https://patchwork.freedesktop.org/series/124599/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13708 -> Patchwork_124599v1
Summary
On Thu, 21 Sep 2023, Jani Nikula wrote:
> Since the edid_firmware module parameter was moved from
> drm_kms_helper.ko to drm.ko in v4.15, we've had a backwards
> compatibility helper in place, with a DRM_NOTE() suggesting to migrate
> to drm.edid_firmware. This was added in commit ac6c35a4d8c7
On Tue, 03 Oct 2023, Jonathan Cavitt wrote:
> Add device info tags for if GuC TLB Invalidation is enabled. Since GuC
> based TLB invalidation is only strictly necessary for MTL presently,
> only enable GuC based TLB invalidations for MTL.
In the subject, what's a "pci tag"?
BR,
Jani.
>
>
On 04/10/2023 10:52, Mathias Krause wrote:
On 03.10.23 09:32, Tvrtko Ursulin wrote:
On 29/09/2023 12:00, Tvrtko Ursulin wrote:
[...]
Thanks again!
Reviewed-by: Tvrtko Ursulin
Patches pushed to drm-intel-gt-next.
Thanks, Tvrtko!
I guess this implies no backport of the first patch to
On Tue, 03 Oct 2023, Ville Syrjälä wrote:
> On Tue, Oct 03, 2023 at 03:42:06PM +0300, Jani Nikula wrote:
>> Continue separation of display code from the rest.
>>
>> Jani Nikula (4):
>> drm/i915: convert INTEL_DISPLAY_ENABLED() into a function
>> drm/i915: move display info related macros to
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.
>
> To prevent GT reset interference, employ gt->reset.mutex instead, since
> intel_gt_mcr_multicast_write relies on gt->uncore->lock not being
On Wed, Oct 04, 2023 at 01:25:04PM +0300, Mika Kahola wrote:
> Every know and then we receive the following error when running
> for example IGT test kms_flip.
>
> [drm] *ERROR* PHY G Read 0d80 failed after 3 retries.
> [drm] *ERROR* PHY G Write 0d81 failed after 3 retries.
>
> Since the error
On Tue, 03 Oct 2023, 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
>
Every know and then we receive the following error when running
for example IGT test kms_flip.
[drm] *ERROR* PHY G Read 0d80 failed after 3 retries.
[drm] *ERROR* PHY G Write 0d81 failed after 3 retries.
Since the error is sporadic in nature, the patch proposes
to reset the message bus after
> -Original Message-
> From: Manna, Animesh
> Sent: Thursday, September 21, 2023 11:44 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org; Nikula, Jani ;
> Hogander, Jouni ; Murthy, Arun R
> ; Manna, Animesh
> Subject: [PATCH v6 6/6] drm/i915/panelreplay:
On Tue, 2023-10-03 at 22:42 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Plane stride is always a multiple of 64 bytes. Remove the
> pointless check that really doesn't have anything to do
> with FBC.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_fbc.c |
> -Original Message-
> From: Manna, Animesh
> Sent: Thursday, September 21, 2023 11:44 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org; Nikula, Jani ;
> Hogander, Jouni ; Murthy, Arun R
> ; Manna, Animesh
> Subject: [PATCH v6 5/6] drm/i915/panelreplay:
== Series Details ==
Series: drm/i915: nuke i915->gt0 (rev3)
URL : https://patchwork.freedesktop.org/series/124508/
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: nuke i915->gt0 (rev3)
URL : https://patchwork.freedesktop.org/series/124508/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13708 -> Patchwork_124508v3
Summary
---
**SUCCESS**
> -Original Message-
> From: Manna, Animesh
> Sent: Thursday, September 21, 2023 11:44 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org; Nikula, Jani ;
> Hogander, Jouni ; Murthy, Arun R
> ; Manna, Animesh
> Subject: [PATCH v6 3/6] drm/i915/panelreplay:
Take the mcr lock only when driver needs to write into a mcr based
tlb based registers.
To prevent GT reset interference, employ gt->reset.mutex instead, since
intel_gt_mcr_multicast_write relies on gt->uncore->lock not being held.
v2: remove unused var, flags.
Signed-off-by: Nirmoy Das
---
On Tue, 26 Sep 2023, Jani Nikula wrote:
> gvt.h has no need to include i915_drv.h once the unused to_gvt() has
> been removed.
>
> Signed-off-by: Jani Nikula
Zhenyu, Zhi, ping?
BR,
Jani.
> ---
> drivers/gpu/drm/i915/gvt/gvt.h | 7 +--
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
== Series Details ==
Series: drm/i915: nuke i915->gt0 (rev3)
URL : https://patchwork.freedesktop.org/series/124508/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13708_full -> Patchwork_124508v3_full
Summary
---
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
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:
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
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
== 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 -> Patchwork_124604v2
Summary
---
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 unnecessary noise in the
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 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
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()
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.
To prevent GT reset interference, employ gt->reset.mutex instead, since
== 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
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
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ä
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 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ä
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ä
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ä
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ä
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ä
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ä
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ä
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
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 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
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
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.
> > >
> > >
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 +-
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
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
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
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]
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, 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:
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,
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
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ä
> ---
>
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
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
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
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
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
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 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.
> > >
> > > > 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 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
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
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
== 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
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
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 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
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
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
---
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) 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 +
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 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
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
1 - 100 of 144 matches
Mail list logo
