== Series Details ==
Series: Introduce DRM device wedged event (rev10)
URL : https://patchwork.freedesktop.org/series/138069/
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: Introduce DRM device wedged event (rev10)
URL : https://patchwork.freedesktop.org/series/138069/
State : warning
== Summary ==
Error: dim checkpatch failed
9e92dc048adb drm: Introduce device wedged event
-:198: WARNING:STATIC_CONST_CHAR_ARRAY: char * array declarat
On 03.02.2025 23:59, Rodrigo Vivi wrote:
> On Tue, Jan 21, 2025 at 09:42:17AM -0500, Rodrigo Vivi wrote:
>> On Sat, Jan 18, 2025 at 06:47:27PM +0100, Michal Wajdeczko wrote:
>>>
>>>
>>> On 17.01.2025 22:57, Vinay Belgaumkar wrote:
Default SLPC power profile is Base(0). Power Saving mode(1)
From: André Almeida
Use DRM's device wedged event to notify userspace that a reset had
happened. For now, only use `none` method meant for telemetry
capture.
In the future we might want to report a recovery method if the reset didn't
succeed.
Acked-by: Shashank Sharma
Signed-off-by: André Alme
Now that we have device wedged event provided by DRM core, make use
of it and support both driver rebind and bus-reset based recovery.
With this in place, userspace will be notified of wedged device on
gt reset failure.
Signed-off-by: Raag Jadav
Reviewed-by: Aravind Iddamsetty
---
drivers/gpu/d
This was previously attempted as xe specific reset uevent but dropped
in commit 77a0d4d1cea2 ("drm/xe/uapi: Remove reset uevent for now")
as part of refactoring.
Now that we have device wedged event provided by DRM core, make use
of it and support both driver rebind and bus-reset based recovery.
W
Add documentation for device wedged event in a new "Device wedging"
chapter. This describes basic definitions, prerequisites and consumer
expectations along with an example.
v8: Improve introduction (Christian, Rodrigo)
v9: Add prerequisites section (Christian)
v10: Clarify mmap cleanup and cons
Introduce device wedged event, which notifies userspace of 'wedged'
(hanged/unusable) state of the DRM device through a uevent. This is
useful especially in cases where the device is no longer operating as
expected and has become unrecoverable from driver context. Purpose of
this implementation is
This series introduces device wedged event in DRM subsystem and uses it
in xe, i915 and amdgpu drivers. Detailed description in commit message.
This was earlier attempted as xe specific uevent in v1 and v2 on [1].
Similar work by André Almeida on [2].
Wedged event support for amdgpu by André Almei
On 2/3/2025 9:44 PM, Mitul Golani wrote:
Avoid full modeset by skipping infoframe.enable check when toggling
AS SDP while enabling VRR or while state change from PSR to VRR,
preventing full modeset while pipe config changes.
I dont think this is related to PSR.
Signed-off-by: Mitul Golani
== Series Details ==
Series: scsi: use GFP_NOIO to avoid circular locking dependency
URL : https://patchwork.freedesktop.org/series/144282/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_16059 -> Patchwork_144282v1
Summary
-
== Series Details ==
Series: scsi: use GFP_NOIO to avoid circular locking dependency
URL : https://patchwork.freedesktop.org/series/144282/
State : warning
== Summary ==
Error: dim checkpatch failed
ab538f49c00a scsi: use GFP_NOIO to avoid circular locking dependency
-:25: WARNING:PREFER_LORE_
From: Rik van Riel
Filesystems can write to disk from page reclaim with __GFP_FS
set. Marc found a case where scsi_realloc_sdev_budget_map
ends up in page reclaim with GFP_KERNEL, where it could try
to take filesystem locks again, leading to a deadlock.
WARNING: possible circular locking depende
On Mon, 3 Feb 2025 10:39:58 +0200 "Kirill A. Shutemov"
wrote:
> > diff --git a/mm/filemap.c b/mm/filemap.c
> > index 4fe551037bf7..98493443d120 100644
> > --- a/mm/filemap.c
> > +++ b/mm/filemap.c
> > @@ -1605,8 +1605,9 @@ static void folio_end_reclaim_write(struct folio
> > *folio)
> >
On 2/3/2025 2:57 AM, Abel Vesa wrote:
Link Training Tunable PHY Repeaters (LTTPRs) are defined in DisplayPort
1.4a specification. As the name suggests, these PHY repeaters are
capable of adjusting their output for link training purposes.
According to the DisplayPort standard, LTTPRs have two
On 2025-02-03 8:29 a.m., Andi Shyti wrote:
Hi,
Please, next time, do not remove the mailing and the other folks
you cc'ed.
I'm adding back the mailing list and Daniele who has commented
before.
Thanks, I also found my previous response click on "reply", not the
"reply all".
...
Clos
Just found my previous response click on "reply", not the "reply all",
so add Cc list.
Regards,
Zhanjun Dong
Forwarded Message
Subject: Re: [PATCH v1] drm/i915/guc: Always disable interrupt ahead of
synchronize_irq
Date: Mon, 27 Jan 2025 17:17:33 -0500
From: Dong, Zhanjun
== Series Details ==
Series: drm/i915/dmc_wl: Track INITIATE_PM_DMD_REQ for DC5
URL : https://patchwork.freedesktop.org/series/144278/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_16058 -> Patchwork_144278v1
Summary
--
On Tue, Jan 21, 2025 at 09:42:17AM -0500, Rodrigo Vivi wrote:
> On Sat, Jan 18, 2025 at 06:47:27PM +0100, Michal Wajdeczko wrote:
> >
> >
> > On 17.01.2025 22:57, Vinay Belgaumkar wrote:
> > > Default SLPC power profile is Base(0). Power Saving mode(1)
> > > has conservative up/down thresholds an
On Sun, Feb 02, 2025 at 10:14:31PM +, Colin Ian King wrote:
> There is a spelling mistake in an error message. Fix it.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu
Quoting Vivi, Rodrigo (2025-02-03 17:59:19-03:00)
>On Mon, 2025-02-03 at 17:40 -0300, Gustavo Sousa wrote:
>> Quoting Vivi, Rodrigo (2025-02-03 17:23:53-03:00)
>> > On Mon, 2025-02-03 at 17:19 -0300, Gustavo Sousa wrote:
>> > > Quoting Imre Deak (2025-02-03 16:22:44-03:00)
>> > > > On Mon, Feb 03,
== Series Details ==
Series: Compute as_sdp when vrr is enabled
URL : https://patchwork.freedesktop.org/series/144268/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_16056 -> Patchwork_144268v1
Summary
---
**SUCCESS**
The Bspec has been updated to include INITIATE_PM_DMD_REQ in the set of
register offsets that require the DMC wakelock for access during DC5.
Update our table accordingly.
Bspec: 71583
Signed-off-by: Gustavo Sousa
---
drivers/gpu/drm/i915/display/intel_dmc_wl.c | 1 +
1 file changed, 1 insertion
On Mon, 2025-02-03 at 17:40 -0300, Gustavo Sousa wrote:
> Quoting Vivi, Rodrigo (2025-02-03 17:23:53-03:00)
> > On Mon, 2025-02-03 at 17:19 -0300, Gustavo Sousa wrote:
> > > Quoting Imre Deak (2025-02-03 16:22:44-03:00)
> > > > On Mon, Feb 03, 2025 at 12:15:26PM -0500, Rodrigo Vivi wrote:
> > > > >
== Series Details ==
Series: Compute as_sdp when vrr is enabled
URL : https://patchwork.freedesktop.org/series/144268/
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:
Quoting Vivi, Rodrigo (2025-02-03 17:23:53-03:00)
>On Mon, 2025-02-03 at 17:19 -0300, Gustavo Sousa wrote:
>> Quoting Imre Deak (2025-02-03 16:22:44-03:00)
>> > On Mon, Feb 03, 2025 at 12:15:26PM -0500, Rodrigo Vivi wrote:
>> > > > > > [...]
>> > > > > >
>> > > > > > The driver enabling DC6 is not
On Mon, 2025-02-03 at 17:19 -0300, Gustavo Sousa wrote:
> Quoting Imre Deak (2025-02-03 16:22:44-03:00)
> > On Mon, Feb 03, 2025 at 12:15:26PM -0500, Rodrigo Vivi wrote:
> > > > > > [...]
> > > > > >
> > > > > > The driver enabling DC6 is not an enough condition for DC6
> > > > > > being allowed
>
Quoting Imre Deak (2025-02-03 16:22:44-03:00)
>On Mon, Feb 03, 2025 at 12:15:26PM -0500, Rodrigo Vivi wrote:
>> > > > [...]
>> > > >
>> > > > The driver enabling DC6 is not an enough condition for DC6 being
>> > > > allowed
>> > > > from the display side. Some display clock gating etc. configurati
== Series Details ==
Series: drm/i915/dp: Add support for DP UHBR SST DSC
URL : https://patchwork.freedesktop.org/series/144265/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_16055 -> Patchwork_144265v1
Summary
---
*
== Series Details ==
Series: drm/i915/dp: Add support for DP UHBR SST DSC
URL : https://patchwork.freedesktop.org/series/144265/
State : warning
== Summary ==
Error: dim checkpatch failed
c130ee4fbab6 drm/i915/dp: Add support for DP UHBR SST DSC
-:50: WARNING:LONG_LINE: line length of 102 exce
== Series Details ==
Series: Use VRR timing generator for fixed refresh rate modes (rev8)
URL : https://patchwork.freedesktop.org/series/134383/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_16055 -> Patchwork_134383v8
Summ
On Mon, Feb 03, 2025 at 12:15:26PM -0500, Rodrigo Vivi wrote:
> > > > [...]
> > > >
> > > > The driver enabling DC6 is not an enough condition for DC6 being allowed
> > > > from the display side. Some display clock gating etc. configuration by
> > > > the driver could be blocking it. According to t
== Series Details ==
Series: Use VRR timing generator for fixed refresh rate modes (rev8)
URL : https://patchwork.freedesktop.org/series/134383/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
+./arch/x86/in
== Series Details ==
Series: drm/i915/selftests: avoid using uninitialized context (rev4)
URL : https://patchwork.freedesktop.org/series/143990/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_16055 -> Patchwork_143990v4
Summ
On Sun, Feb 02, 2025 at 06:28:08AM -0800, Guenter Roeck wrote:
> On 2/2/25 05:27, David Laight wrote:
> > On Tue, 21 Jan 2025 15:15:09 -0800
> > Linus Torvalds wrote:
> >
> > > On Tue, 21 Jan 2025 at 14:59, Rodrigo Vivi wrote:
> > > >
> > > > I'm pushing this soon to drm-intel-next, unless Linu
== Series Details ==
Series: drm/i915/dmc: Add debugfs for dc6 counter
URL : https://patchwork.freedesktop.org/series/144240/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_16054 -> Patchwork_144240v1
Summary
---
**SU
== Series Details ==
Series: drm/dp: Rework LTTPR transparent mode handling and add support to msm
driver
URL : https://patchwork.freedesktop.org/series/144246/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_16054 -> Patchwork_144246v1
=
== Series Details ==
Series: drm/dp: Rework LTTPR transparent mode handling and add support to msm
driver
URL : https://patchwork.freedesktop.org/series/144246/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separatel
On Mon, Feb 03, 2025 at 06:51:17PM +0200, Imre Deak wrote:
> On Mon, Feb 03, 2025 at 11:42:11AM -0500, Rodrigo Vivi wrote:
> > On Mon, Feb 03, 2025 at 06:27:17PM +0200, Imre Deak wrote:
> > > On Mon, Feb 03, 2025 at 11:12:34AM -0500, Rodrigo Vivi wrote:
> > > > On Mon, Feb 03, 2025 at 06:01:25PM +0
== Series Details ==
Series: drm/i915/dmc: Add debugfs for dc6 counter
URL : https://patchwork.freedesktop.org/series/144240/
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/dmc: Add debugfs for dc6 counter
URL : https://patchwork.freedesktop.org/series/144240/
State : warning
== Summary ==
Error: dim checkpatch failed
ac35a2baaed3 drm/i915/dmc: Add debugfs for dc6 counter
-:6: WARNING:COMMIT_LOG_LONG_LINE: Prefer a maximum 75
On Mon, Feb 03, 2025 at 11:42:11AM -0500, Rodrigo Vivi wrote:
> On Mon, Feb 03, 2025 at 06:27:17PM +0200, Imre Deak wrote:
> > On Mon, Feb 03, 2025 at 11:12:34AM -0500, Rodrigo Vivi wrote:
> > > On Mon, Feb 03, 2025 at 06:01:25PM +0200, Imre Deak wrote:
> > > > On Mon, Feb 03, 2025 at 10:45:58AM -0
On Mon, Feb 03, 2025 at 01:37:17PM -0300, Gustavo Sousa wrote:
> Quoting Imre Deak (2025-02-03 12:14:10-03:00)
> >On Mon, Feb 03, 2025 at 11:59:59AM -0300, Gustavo Sousa wrote:
> >> Quoting Imre Deak (2025-02-03 11:26:19-03:00)
> >> >On Mon, Feb 03, 2025 at 10:39:54AM -0300, Gustavo Sousa wrote:
>
On Mon, Feb 03, 2025 at 06:27:17PM +0200, Imre Deak wrote:
> On Mon, Feb 03, 2025 at 11:12:34AM -0500, Rodrigo Vivi wrote:
> > On Mon, Feb 03, 2025 at 06:01:25PM +0200, Imre Deak wrote:
> > > On Mon, Feb 03, 2025 at 10:45:58AM -0500, Rodrigo Vivi wrote:
> > > > On Mon, Feb 03, 2025 at 05:14:10PM +0
Quoting Imre Deak (2025-02-03 12:14:10-03:00)
>On Mon, Feb 03, 2025 at 11:59:59AM -0300, Gustavo Sousa wrote:
>> Quoting Imre Deak (2025-02-03 11:26:19-03:00)
>> >On Mon, Feb 03, 2025 at 10:39:54AM -0300, Gustavo Sousa wrote:
>> >> Quoting Imre Deak (2025-02-03 09:43:38-03:00)
>> >> >On Mon, Feb 03
Avoid full modeset by skipping infoframe.enable check when toggling
AS SDP while enabling VRR or while state change from PSR to VRR,
preventing full modeset while pipe config changes.
Signed-off-by: Mitul Golani
---
drivers/gpu/drm/i915/display/intel_display.c | 6 --
1 file changed, 4 inser
On Mon, Feb 03, 2025 at 11:12:34AM -0500, Rodrigo Vivi wrote:
> On Mon, Feb 03, 2025 at 06:01:25PM +0200, Imre Deak wrote:
> > On Mon, Feb 03, 2025 at 10:45:58AM -0500, Rodrigo Vivi wrote:
> > > On Mon, Feb 03, 2025 at 05:14:10PM +0200, Imre Deak wrote:
> > > > On Mon, Feb 03, 2025 at 11:59:59AM -0
On Mon, Feb 03, 2025 at 06:01:25PM +0200, Imre Deak wrote:
> On Mon, Feb 03, 2025 at 10:45:58AM -0500, Rodrigo Vivi wrote:
> > On Mon, Feb 03, 2025 at 05:14:10PM +0200, Imre Deak wrote:
> > > On Mon, Feb 03, 2025 at 11:59:59AM -0300, Gustavo Sousa wrote:
> > > > Quoting Imre Deak (2025-02-03 11:26:
Compute as sdp when vrr.enable is set, also Skip
infoframe.enable check to avoid full modeset during
as_sdp toggle.
Mitul Golani (2):
drm/i915/display: Skip state checker for AS SDP infoframe enable
drm/i915/dp: Compute AS SDP only when vrr.enable is set
drivers/gpu/drm/i915/display/intel_di
Compute AS SDP params only when VRR is enabled to
maintain PSR exclusivity.
Signed-off-by: Mitul Golani
---
drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp
Drop the UHBR limitation from DP SST DSC, and handle SST DSC bandwidth
computation for UHBR using intel_dp_mtp_tu_compute_config().
Cc: Imre Deak
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_dp.c | 35 +++--
1 file changed, 27 insertions(+), 8 deletions(
On Mon, Feb 03, 2025 at 10:45:58AM -0500, Rodrigo Vivi wrote:
> On Mon, Feb 03, 2025 at 05:14:10PM +0200, Imre Deak wrote:
> > On Mon, Feb 03, 2025 at 11:59:59AM -0300, Gustavo Sousa wrote:
> > > Quoting Imre Deak (2025-02-03 11:26:19-03:00)
> > > >On Mon, Feb 03, 2025 at 10:39:54AM -0300, Gustavo
On 31/01/2025 23:11, Lucas De Marchi wrote:
Since commit 4ba4f1afb6a9 ("perf: Generic hotplug support for a PMU with
a scope"), there's generic support for system-wide counters and
integration with cpu hotplug.
The i915 counters are system-wide, even though the migration code
is using the wron
On 2025-01-31 6:11 p.m., Lucas De Marchi wrote:
> Since commit 4ba4f1afb6a9 ("perf: Generic hotplug support for a PMU with
> a scope"), there's generic support for system-wide counters and
> integration with cpu hotplug.
>
> The i915 counters are system-wide, even though the migration code
> is
On Mon, Feb 03, 2025 at 11:23:23AM +0200, Jani Nikula wrote:
> On Mon, 03 Feb 2025, Mohammed Thasleem wrote:
> > Starting from MTl we don't have a platform agnostic way to validate DC6
> > state
> > due to dc6 counter has been removed to validate DC state.
> > Adding dc6_entry_counter at display
On Mon, Feb 03, 2025 at 05:14:10PM +0200, Imre Deak wrote:
> On Mon, Feb 03, 2025 at 11:59:59AM -0300, Gustavo Sousa wrote:
> > Quoting Imre Deak (2025-02-03 11:26:19-03:00)
> > >On Mon, Feb 03, 2025 at 10:39:54AM -0300, Gustavo Sousa wrote:
> > >> Quoting Imre Deak (2025-02-03 09:43:38-03:00)
> >
On Mon, Feb 03, 2025 at 11:59:59AM -0300, Gustavo Sousa wrote:
> Quoting Imre Deak (2025-02-03 11:26:19-03:00)
> >On Mon, Feb 03, 2025 at 10:39:54AM -0300, Gustavo Sousa wrote:
> >> Quoting Imre Deak (2025-02-03 09:43:38-03:00)
> >> >On Mon, Feb 03, 2025 at 02:26:13PM +0530, Mohammed Thasleem wrote
Quoting Imre Deak (2025-02-03 11:26:19-03:00)
>On Mon, Feb 03, 2025 at 10:39:54AM -0300, Gustavo Sousa wrote:
>> Quoting Imre Deak (2025-02-03 09:43:38-03:00)
>> >On Mon, Feb 03, 2025 at 02:26:13PM +0530, Mohammed Thasleem wrote:
>> >> Starting from MTl we don't have a platform agnostic way to vali
On Fri, 31 Jan 2025, Imre Deak wrote:
> On Fri, Jan 31, 2025 at 02:49:54PM +0200, Jani Nikula wrote:
>> Commit 1c56e9a39833 ("drm/i915/dp: Get optimal link config to have best
>> compressed bpp") tries to find the best compressed bpp for the
>> link. However, it iterates from max to min bpp on dis
On Mon, Feb 03, 2025 at 12:57:55PM +0200, Abel Vesa wrote:
> Looking at both i915 and nouveau DP drivers, both are setting the first
> LTTPR (if found) in transparent mode first and then in non-transparent
> mode, just like the DP v2.0 specification mentions in section 3.6.6.1.
>
> Being part of t
On Sun, Feb 02, 2025 at 07:40:35PM +0900, Vincent Mailhol wrote:
Hi Lucas and Yury,
On 08/02/2024 at 16:45, Lucas De Marchi wrote:
ove the implementation of REG_GENMASK/REG_BIT to a more appropriate
place to be shared by i915, xe and possibly other parts of the kernel.
For now this re-defines
On Mon, Feb 03, 2025 at 10:39:54AM -0300, Gustavo Sousa wrote:
> Quoting Imre Deak (2025-02-03 09:43:38-03:00)
> >On Mon, Feb 03, 2025 at 02:26:13PM +0530, Mohammed Thasleem wrote:
> >> Starting from MTl we don't have a platform agnostic way to validate DC6
> >> state
> >> due to dc6 counter has b
On 1/30/2025 4:38 PM, Nautiyal, Ankit K wrote:
On 1/25/2025 3:23 AM, Ville Syrjälä wrote:
On Fri, Jan 24, 2025 at 08:30:16PM +0530, Ankit Nautiyal wrote:
To work seamlessly between variable and fixed timings,
intel_vrr_{enable,disable}() should just flip between the fixed and
variable timing
Quoting Imre Deak (2025-02-03 09:43:38-03:00)
>On Mon, Feb 03, 2025 at 02:26:13PM +0530, Mohammed Thasleem wrote:
>> Starting from MTl we don't have a platform agnostic way to validate DC6 state
>> due to dc6 counter has been removed to validate DC state.
>> Adding dc6_entry_counter at display dirv
Hi,
Please, next time, do not remove the mailing and the other folks
you cc'ed.
I'm adding back the mailing list and Daniele who has commented
before.
...
> > > Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13454
> > > Fixes: 26705e20752a ("drm/i915: Support for GuC interrupts
For fixed refresh rate timings, the VRR TG is not disabled and timings
are changed on the fly.
Modify the check for warning for changing timings with VRR TG disabled.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_vblank.c | 10 +++---
1 file changed, 7 insertions(+), 3
Currently VRR timing generator is used only when VRR is enabled by
userspace. From MTL+, gradually move away from older timing
generator and use VRR timing generator for fixed refresh rate also.
In such a case, Flipline Vmin and Vmax all are set to the Vtotal of the
mode, which effectively makes t
Make provision for fixed refresh rate timings while updating the
crtc timings for vrr.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_vblank.c | 5 +
drivers/gpu/drm/i915/display/intel_vrr.c| 7 ++-
drivers/gpu/drm/i915/display/intel_vrr.h| 2 ++
3 files cha
During modeset enable sequence, program the fixed timings,
and turn on the VRR Timing Generator (VRR TG) for platforms
that always use VRR TG.
Later if vrr timings are required, vrr_enable() will switch
to the real VRR timings.
With this we dont want to set the vrr timings during
intel_pre_update
Wa_14015406119 is required for PSR1/2 while working with fixed refresh
rate with VRR timing generator.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_display.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_displa
For platforms for which vrr timing generator is always set, VRR_CTL
enable bit does not need to toggle, so modify the vrr_{enable/disable}
for this.
At the moment the helper intel_vrr_always_use_vrr_tg() return false for
all cases. This will be set later when all other bits are in place.
Signed-of
LRR and Vmax can be computed only if VRR is supported and vrr.in_range
is set. Currently we proceed with vrr timings only for VRR supporting
panels and return otherwise. For using VRR TG with fix timings, need to
continue even for panels that do not support VRR.
To achieve this, refactor the condi
Modify the helper intel_crtc_update_active_timings() to update the
timings based on the given vrr.mode.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_display.c | 6 +++---
drivers/gpu/drm/i915/display/intel_vblank.c | 22
drivers/gpu/drm/i915/display
Do not program transcoder registers for VRR for the secondary pipe of
the joiner. Remove check to skip VRR for joiner case.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_vrr.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/
At the moment PSR/PSR2 are not supported with variable refresh rate.
However it can be supported with fixed refresh rate while running with
VRR timing generator.
Enable PSR for fixed refresh rate when using the VRR timing generator.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/
As per bspec 49268: Disable PSR before disabling VRR.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_display.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.
Add support for using VRR Timing generator for HDMI panels.
Signed-off-by: Ankit Nautiyal
Reviewed-by: Mitul Golani
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/inte
MSA Ignore Timing PAR enable is set in the DP sink when we enable variable
refresh rate. When using VRR timing generator for fixed refresh rate
we do not want to ignore the mode timings, as the refresh rate is still
fixed. Modify the checks to enable MSA Ignore Timing PAR only when not
in fixed_rr
VRR timing generator can be used even with fixed refresh rate.
With this the legacy timing generator can be phased out and VRR timing
generator can be used for all cases, whether panels support VRR or not.
Add an enum value to represent the VRR timing generator in
fixed refresh rate mode and updat
Currently we do not support VRR with HDMI so skip vrr compute
config step for DP with HDMI sink.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers
Currently we always compute the timings as if vrr is enabled.
With this approach the state checker becomes complicated when we
introduce fixed refresh rate mode with vrr timing generator.
To avoid the complications, instead of always computing vrr timings, we
compute vrr timings based on uapi.vrr_
With CMRR the vrr.enable was tracking the vrr timing generator, which made
the helpers intel_crtc_vrr_{enable/disable} also track the
vrr timing generator.
Since we don not have CMRR now, the crtc_vrr_{enable/disable} should now
track the vrr mode of operation of the vrr timing generator.
Update t
To have fixed refresh rate with VRR timing generator the
guardband/pipeline full can't be programmed on the fly. So we need to
ensure that the values satisfy both the fixed and variable refresh
rates.
Since we compute these value based on vmin, lets set the vmin to
crtc_vtotal for both fixed and v
Print Vrr mode along with other vrr members in crtc_state dump.
Signed-off-by: Ankit Nautiyal
---
.../drm/i915/display/intel_crtc_state_dump.c| 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
b/drivers/
Switching between variable and fixed timings is possible as for that we
just need to flip between VRR timings. However for CMRR along with the
timings, few other bits also need to be changed on the fly, which might
cause issues. So disable CMRR for now, till we have variable and fixed
timings sorte
Since cmrr is now one of the mode of operation of VRR timing generator,
move its elements in the vrr struct.
Replace cmrr.enable with vrr.mode INTEL_VRRTG_MODE_CMRR and move cmrr_m
and cmrr_n in vrr struct.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_display.c | 19 +++
Since we now have vrr.mode to track the mode in which the VRR timing
generator is running, we no longer need member vrr.enable.
Replace the check for vrr.enable and use a helper to check
vrr.mode != NONE.
Signed-off-by: Ankit Nautiyal
---
.../drm/i915/display/intel_crtc_state_dump.c | 2 +-
d
Fill vrr.mode during compute_config and update intel_vrr_get_config() to
read vrr.mode based on CMRR and VRR enable conditions.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_display.c | 1 +
drivers/gpu/drm/i915/display/intel_vrr.c | 5 +
2 files changed, 6 inserti
The VRR timing generator can be used in multiple modes of operation:
dynamic refresh rate (VRR), content-matched refresh rate (CMRR), and
fixed refresh rate (Fixed_RR).
Currently, VRR and CMRR modes are supported, with Fixed_RR mode
forthcoming.
To track the different operational modes of the VRR
Combine the CMRR capability and enable check into a single condition.
Set crtc_state->cmrr.enable directly within the combined condition.
This will make way to absorb cmrr members in vrr struct.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_vrr.c | 5 ++---
1 file changed,
Separate out functions for computing cmrr and vrr timings.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_vrr.c | 45 +++-
1 file changed, 28 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c
b/drivers/gpu/drm/i915/di
Make helpers to compute vmin and vmax.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_vrr.c | 39 +++-
1 file changed, 31 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c
b/drivers/gpu/drm/i915/display/intel_vrr.c
ind
The comment about fixed average vtotal is incorrect.
Remove it.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_vrr.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c
b/drivers/gpu/drm/i915/display/intel_vrr.c
index adb51609d0
Even though the VRR timing generator (TG) is primarily used for
variable refresh rates, it can be used for fixed refresh rates as
well. For a fixed refresh rate the Flip Line and Vmax must be equal
(TRANS_VRR_FLIPLINE = TRANS_VRR_VMAX). Beyond that, there are some
dependencies between the VRR timin
On Mon, Feb 03, 2025 at 02:26:13PM +0530, Mohammed Thasleem wrote:
> Starting from MTl we don't have a platform agnostic way to validate DC6 state
> due to dc6 counter has been removed to validate DC state.
> Adding dc6_entry_counter at display dirver to validate dc6 state.
>
> Signed-off-by: Moha
On 28.01.2025 10:29, Krzysztof Karas wrote:
Hi Maciej,
The locked==true looks OK.
thanks for review!
However, I fear that there is some corner case with locked==false. 1 or 2
calls back in chain looks good.
CI failures needs to be analyzed.
Yup, I already did that recently. I thought th
Quoting Lucas De Marchi (2025-01-31 20:49:35-03:00)
>On Fri, Jan 31, 2025 at 05:16:29PM -0300, Gustavo Sousa wrote:
>>Quoting Krzysztof Karas (2025-01-30 11:18:28-03:00)
>>>Hi Gustavo,
>>>
>>>[...]
Let's remove that check, since it is unnecessary and causes the
inconsistency illustrated a
LTTPRs operating modes are defined by the DisplayPort standard and the
generic framework now provides a helper to switch between them, which
is handling the explicit disabling of non-transparent mode and its
disable->enable sequence mentioned in the DP Standard v2.0 section
3.6.6.1.
So use the new
According to the DisplayPort standard, LTTPRs have two operating
modes:
- non-transparent - it replies to DPCD LTTPR field specific AUX
requests, while passes through all other AUX requests
- transparent - it passes through all AUX requests.
Switching between this two modes is done by the DPT
Link Training Tunable PHY Repeaters (LTTPRs) are defined in DisplayPort
1.4a specification. As the name suggests, these PHY repeaters are
capable of adjusting their output for link training purposes.
According to the DisplayPort standard, LTTPRs have two operating
modes:
- non-transparent - it re
1 - 100 of 105 matches
Mail list logo
