== Series Details ==
Series: Fix vrr.enable handling and add logging for fixed_rr
URL : https://patchwork.freedesktop.org/series/146619/
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/as
Currently, vrr.enable is intended only for variable refresh rate timings.
At this point, we do not set fixed refresh rate timings, but the GOP can,
which creates a problem during the readback of vrr.enable.
The GOP enables the VRR timing generator with fixed timings, while the
driver only recogniz
This series is split from the main series [1] for merging the fixes early,
while other patches of the series are still in review:
The commit:
a27217f9d1856 ("drm/i915/vrr: Track vrr.enable only for variable timing")
adds a change in reading the vrr.enable, which is causing issue when GOP
enables V
Add fixed refresh rate mode in crtc_state dump.
VRR Timing Generator is running in fixed refresh rate mode when
vrr.vmin = vrr.vmax = vrr.flipline.
v2: s/fixed_rr/fixed rr for consistency with the other stuff. (Ville)
Signed-off-by: Ankit Nautiyal
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm
On Fri, Mar 21, 2025 at 11:10:05PM +0530, Nautiyal, Ankit K wrote:
>
> On 3/21/2025 11:04 PM, Ville Syrjälä wrote:
> > On Tue, Mar 18, 2025 at 01:05:26PM +0530, Ankit Nautiyal wrote:
> >> Currently, vrr.enable is intended only for variable refresh rate timings.
> >> At this point, we do not set fi
On Tue, Mar 04, 2025 at 04:57:58PM +0100, Enrico Weigelt, metux IT consult
wrote:
> Xserver includes have explicit pointer types for quite all kind of structs
> (at least those used by drivers), which are used all over the Xserver.
> Thus it's much cleaner to use those everywhere.
>
> This commit
On Tue, Mar 04, 2025 at 04:58:02PM +0100, Enrico Weigelt, metux IT consult
wrote:
> the function has become a no-op, it's former duties are done automatically.
s/the function/xf86_reload_cursors()/
Could use xserver commit references as well.
>
> Signed-off-by: Enrico Weigelt, metux IT consult
On Tue, Mar 04, 2025 at 04:57:57PM +0100, Enrico Weigelt, metux IT consult
wrote:
> The Xserver's System() function is a special wrapper for calling a program
> (xkbcomp) as an unprivileged user, when the Xserver is running as suid-root.
> (which today only needed on a few platforms, eg. Solaris).
On Tue, Mar 04, 2025 at 04:58:06PM +0100, Enrico Weigelt, metux IT consult
wrote:
> tools/meson.build:45: WARNING: Project targets '>0.40.0' but uses feature
> introduced in '0.41.0': capture arg in configure_file.
> 377tools/meson.build:45: WARNING: Project targets '>0.40.0' but uses feature
>
On Fri, Mar 21, 2025 at 01:35:16AM -0500, Lucas De Marchi wrote:
> On Fri, Feb 14, 2025 at 01:59:44PM -0800, Vivek Kasireddy wrote:
> > Some SKUs of Xe2_HPD platforms (such as BMG) have GDDR memory type
> > with ECC enabled. We need to identify this scenario and add a new
> > case in xelpdp_get_dra
On Tue, Mar 04, 2025 at 04:58:07PM +0100, Enrico Weigelt, metux IT consult
wrote:
> Silence warnings.
>
> Signed-off-by: Enrico Weigelt, metux IT consult
> ---
> benchmarks/dri3-swap.c | 2 ++
> src/intel_list.h | 3 +++
> test/present-speed.c | 2 ++
Looks like I never added the benchm
On Tue, Mar 04, 2025 at 04:58:04PM +0100, Enrico Weigelt, metux IT consult
wrote:
> xnfcalloc is just an alias for XNFcallocarray() that doesn't seem to serve
> any practical purpose, so it can go away once all drivers stopped using it.
>
> Signed-off-by: Enrico Weigelt, metux IT consult
> ---
>
On Tue, Mar 04, 2025 at 04:58:01PM +0100, Enrico Weigelt, metux IT consult
wrote:
> These are just wrappers for calling input_lock()/input_unlock() and marked
> deprecated for quite a while now.
Listing the relevant xserver commit(s) would be nice here too.
>
> Signed-off-by: Enrico Weigelt, me
On Tue, Mar 04, 2025 at 04:57:55PM +0100, Enrico Weigelt, metux IT consult
wrote:
> The Xserver has been moved to using pixman for all matrix operations, back in
> 2008, but left some #define's so drivers still compile. Since 1.5 decades have
> passed now, it's time to fix remaining drivers still
On Tue, Mar 04, 2025 at 04:57:54PM +0100, Enrico Weigelt, metux IT consult
wrote:
> libXv needs be be explicitly linked, otherwise getting error:
>
> FAILED: xvmc/libIntelXvMC.so.1.0.0
> cc -o xvmc/libIntelXvMC.so.1.0.0
> xvmc/libIntelXvMC.so.1.0.0.p/intel_xvmc.c.o
> xvmc/libIntelXvMC.so.1
On Fri, Mar 21, 2025 at 04:56:25PM +0200, Imre Deak wrote:
> The Panel Power Sequencer lock held on an eDP port (a) blocks a DP AUX
> transfer on another port (b), since the PPS lock is device global, thus
> shared by all ports. The PPS lock can be held on port (a) for a longer
> period due to the
Hi Krzysztof,
On 2025-03-19 at 14:01:17 GMT, Krzysztof Karas wrote:
> Some references to a perf stream in i915_oa_init_reg_state()
> might remain active after its destruction in
> i915_perf_release(). This could cause a read after free
> condition as seen in issue #13756.
>
> Since i915_oa_init_r
On Fri, Mar 21, 2025 at 08:44:22PM +0200, Ville Syrjälä wrote:
> On Fri, Mar 21, 2025 at 08:38:45PM +0200, Imre Deak wrote:
> > On Fri, Mar 21, 2025 at 08:00:29PM +0200, Ville Syrjälä wrote:
> > > On Fri, Mar 21, 2025 at 04:56:25PM +0200, Imre Deak wrote:
> > > > The Panel Power Sequencer lock held
Going forward, struct intel_display is the main display device data
pointer. Convert as much as possible of intel_lvds.[ch] to struct
intel_display.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 11 +-
drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
driv
On Fri, Mar 21, 2025 at 08:38:45PM +0200, Imre Deak wrote:
> On Fri, Mar 21, 2025 at 08:00:29PM +0200, Ville Syrjälä wrote:
> > On Fri, Mar 21, 2025 at 04:56:25PM +0200, Imre Deak wrote:
> > > The Panel Power Sequencer lock held on an eDP port (a) blocks a DP AUX
> > > transfer on another port (b),
On Fri, Mar 21, 2025 at 08:31:22PM +0200, Ville Syrjälä wrote:
> On Fri, Mar 21, 2025 at 04:56:47PM +0530, Ankit Nautiyal wrote:
> > LINK_N register has bits 31:24 for extended link N value used for
> > HDMI2.1 and for an alternate mode of operation of DP TG DDA
> > (Bspec:50488).
> >
> > Add supp
On Fri, Mar 21, 2025 at 08:00:29PM +0200, Ville Syrjälä wrote:
> On Fri, Mar 21, 2025 at 04:56:25PM +0200, Imre Deak wrote:
> > The Panel Power Sequencer lock held on an eDP port (a) blocks a DP AUX
> > transfer on another port (b), since the PPS lock is device global, thus
> > shared by all ports.
On Fri, Mar 21, 2025 at 04:56:47PM +0530, Ankit Nautiyal wrote:
> LINK_N register has bits 31:24 for extended link N value used for
> HDMI2.1 and for an alternate mode of operation of DP TG DDA
> (Bspec:50488).
>
> Add support for these extra bits.
>
> For displays with version 14 or higher, the
== Series Details ==
Series: Introduce drm sharpness property (rev11)
URL : https://patchwork.freedesktop.org/series/138754/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_16300 -> Patchwork_138754v11
Summary
---
**SU
On Fri, Mar 21, 2025 at 04:56:26PM +0200, Imre Deak wrote:
> Use intel_pps_is_pipe_instance() instead of open-coding the same for all
> conditional PPS programming required for a pipe instance PPS.
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/g4x_dp.c| 6 +++---
> drive
On Tue, Mar 18, 2025 at 01:05:39PM +0530, Ankit Nautiyal wrote:
> Currently, the VRR timing generator is used only when VRR is enabled by
> userspace for sinks that support VRR. Starting with PTL+, gradually move
> away from the legacy timing generator and use the VRR timing generator
> for both va
On Tue, Mar 18, 2025 at 01:05:33PM +0530, Ankit Nautiyal wrote:
> For platforms that enable VRR TG only for variable timings, the
> VRR_CTL.VRR_ENABLE bit indicates VRR is active. For platforms that
> always have VRR TG enabled, the VRR_CTL.VRR_ENABLE bit indicates VRR
> is active only when not in
On Tue, Mar 18, 2025 at 01:05:30PM +0530, Ankit Nautiyal wrote:
> In intel_post_plane_update() there are things which might need to do
> vblank waits, so enabling PSR as early as we do now is simply
> counter-productive. Therefore move intel_psr_post_plane_update() at the
> last of intel_post_plane
On Tue, Mar 18, 2025 at 01:05:28PM +0530, Ankit Nautiyal wrote:
> Currently the variable timings are supported only for DP and eDP and not
> for DP MST. Call intel_vrr_compute_config() for MST which will configure
> fixed refresh rate timings irrespective of whether VRR is supported or
> not. Since
== Series Details ==
Series: drm/i915/selftest: allow larger memory allocation (rev2)
URL : https://patchwork.freedesktop.org/series/146321/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_16299 -> Patchwork_146321v2
Summary
Going forward, struct intel_display is the main display device data
pointer. Convert as much as possible of vlv_dsi.[ch] to struct
intel_display.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 4 +-
drivers/gpu/drm/i915/display/vlv_dsi.c | 157 +
== Series Details ==
Series: drm/i915/selftests: Refactor RC6 power measurement and error handling
(rev5)
URL : https://patchwork.freedesktop.org/series/145766/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_16299 -> Patchwork_145766v5
=
To support Link M/N ratio between 10.0 and 15.0, for some BMG ultrajoiner
cases we need Wa_14021768792.
To bypass the hardware limitation within the Timing Generator DDA (TGDDA),
we need to program the LINKM and LINKN registers as defined in
the WA. Along with this we also need relvant bits in HDM
Set the mode of scaler to HQ for casf.
Signed-off-by: Nemesa Garg
---
drivers/gpu/drm/i915/display/skl_scaler.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/skl_scaler.c
b/drivers/gpu/drm/i915/display/skl_scaler.c
index d816dae9cec4..93a847c05535 100644
--
Write the casf registers bits to enable the sharpness
and to compute the strength of casf using casf_compute_config.
Also verify whether the enable bit is set or not and strength
value is correctly updated.
v2: Update subject[Ankit]
Signed-off-by: Nemesa Garg
---
drivers/gpu/drm/i915/display/in
sharpness
As only second scaler can be used for sharpness check if it
is available and also check if panel fitting is not enabled,
then set the sharpness as both uses pipe scaler so only one
can be enabled at a time.
v2: Add the panel fitting check before enabling sharpness
v3: Reframe commit mes
Compute the values for second scaler for sharpness.
Fill the register bits corresponding to the scaler.
v1: Rename the title of patch [Ankit]
v2: Remove setup_casf from here[Ankit]
Signed-off-by: Nemesa Garg
Reviewed-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_casf.c | 1 +
driv
register
The strength value for sharpness is based on user input and
the winsize is based on resolution. Set the casf_enable flag
if there is a platform support and uapi strength is not zero.
Once the sharpness is enabled then just update the strength
bit of the register everytime whenever user ch
Many a times images are blurred or upscaled content is also not as
crisp as original rendered image. Traditional sharpening techniques often
apply a uniform level of enhancement across entire image, which sometimes
result in over-sharpening of some areas and potential loss of natural details.
In
On Thu, Mar 20, 2025 at 02:32:55PM +0800, Baokun Li wrote:
> On 2025/3/20 13:23, Chia-Lin Kao (AceLan) wrote:
> > On Thu, Mar 20, 2025 at 11:52:20AM +0800, Baokun Li wrote:
> > > On 2025/3/20 10:49, AceLan Kao wrote:
> > > > Hi all,
> > > >
> > > > We have found a regression while doing a memory s
Use intel_pps_is_pipe_instance() instead of open-coding the same for all
conditional PPS programming required for a pipe instance PPS.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/g4x_dp.c| 6 +++---
drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
drivers/gpu/drm/i915/display
== Series Details ==
Series: drm/i915/gvt: use hardcoded reference clocks (rev3)
URL : https://patchwork.freedesktop.org/series/146222/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_16299 -> Patchwork_146222v3
Summary
-
== Series Details ==
Series: drm/i915/gvt: use hardcoded reference clocks (rev3)
URL : https://patchwork.freedesktop.org/series/146222/
State : warning
== Summary ==
Error: patch
https://patchwork.freedesktop.org/api/1.0/series/146222/revisions/3/mbox/ not
found
== Series Details ==
Series: drm/i915/dmc: Create debugfs entry for dc6 counter
URL : https://patchwork.freedesktop.org/series/146592/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_16299 -> Patchwork_146592v1
Summary
--
== Series Details ==
Series: drm/i915/dmc: Create debugfs entry for dc6 counter
URL : https://patchwork.freedesktop.org/series/146592/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_16299 -> Patchwork_146592v1
Summary
--
On Fri, Mar 21, 2025 at 01:54:44PM +0100, Andi Shyti wrote:
> Hi Jose,
>
> On Thu, Mar 06, 2025 at 01:08:27PM -0800, José Roberto de Souza wrote:
> > Commit 255fc1703e42 ("drm/i915/gem: Calculate object page offset for
> > partial memory mapping")
> > was the last patch of several patches fixing
== Series Details ==
Series: Implement Wa_14021768792 to bypass m_n ratio limit (rev4)
URL : https://patchwork.freedesktop.org/series/138257/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_16299 -> Patchwork_138257v4
Summary
Hi Jose,
On Thu, Mar 06, 2025 at 01:08:27PM -0800, José Roberto de Souza wrote:
> Commit 255fc1703e42 ("drm/i915/gem: Calculate object page offset for partial
> memory mapping")
> was the last patch of several patches fixing multiple partial mmaps.
> But without a bump in I915_PARAM_MMAP_GTT_VERS
On Fri, Mar 21, 2025 at 02:37:15PM +0200, Jani Nikula wrote:
> On Wed, 19 Mar 2025, "Jason A. Donenfeld" wrote:
> > Hi Andi,
> >
> > On Thu, Feb 13, 2025 at 06:19:12PM +0100, Andi Shyti wrote:
> >> Hi Markus,
> >>
> >> On Tue, Feb 11, 2025 at 07:33:30AM +0100, Markus Theil wrote:
> >> > This is p
For Platforms that support higher link rates, there is a limitation on
Link M /Link N ratio.
If the CEILING( Link M / Link N ) ratio is greater than 10.0, then
hardware cannot support the given resolution / refresh rate at the given
configuration.
For BMG Wa_14021768792 helps to bypass this limitat
== Series Details ==
Series: drm/i915/display: yet another batch of struct intel_display conversions
URL : https://patchwork.freedesktop.org/series/146582/
State : warning
== Summary ==
Error: dim checkpatch failed
ea9cbbd3558f drm/i915/dsi: convert vlv_dsi.[ch] to struct intel_display
-:682:
== Series Details ==
Series: drm/i915: Disable RPG during live selftest (rev4)
URL : https://patchwork.freedesktop.org/series/143886/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_16299 -> Patchwork_143886v4
Summary
---
== Series Details ==
Series: drm/i915/fbc: disable FBC if PSR2 selective fetch is enabled (rev2)
URL : https://patchwork.freedesktop.org/series/146403/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_16299 -> Patchwork_146403v2
===
Going forward, struct intel_display is the main display device data
pointer. Convert intel_tc.c to struct intel_display.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_tc.c | 265
1 file changed, 127 insertions(+), 138 deletions(-)
diff --git a/driver
Going forward, struct intel_display is the main display device data
pointer. Convert as much as possible of intel_pch_display.[ch] to struct
intel_display.
Signed-off-by: Jani Nikula
---
.../drm/i915/display/intel_fifo_underrun.c| 4 +-
.../drm/i915/display/intel_modeset_setup.c| 2 +
Going forward, struct intel_display is the main display device data
pointer. Convert as much as possible of intel_dsi_vbt.[ch] to struct
intel_display.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 131 +--
1 file changed, 63 insertions(+), 68 dele
Going forward, struct intel_display is the main display device data
pointer. Convert intel_dsi_dcs_backlight.c to struct intel_display.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a
The DSI VBT initialization debug logs a lot of parameters. Convert this
to use struct drm_printer with a prefix.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 80 +---
1 file changed, 35 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/
More conversions to struct intel_display.
Jani Nikula (12):
drm/i915/dsi: convert vlv_dsi.[ch] to struct intel_display
drm/i915/dsi: convert vlv_dsi_pll.[ch] to struct intel_display
drm/i915/dsi: convert parameter printing to drm_printer
drm/i915/dsi: convert intel_dsi_vbt.[ch] to struct i
Going forward, struct intel_display is the main display device data
pointer. Convert as much as possible of vlv_dsi_pll.[ch] to struct
intel_display.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 3 +-
drivers/gpu/drm/i915/display/vlv_dsi.c | 3 +-
drive
There are two panel_replay scenarios fbc wa need to be aware of,
panel replay with and without selective update capability.
Panel replay without selective update don't have any fbc wa.
So keep the fbc psr1 wa as it is.
The current fbc psr2 wa is mainly about selective fetch and we
need to apply th
Disable FBC in case PSR2 selective fetch is enabled for all
platforms from display version 12. Later on there will be
mechanism to select between selective fetch and FBC based
on the dirty rect percentage.
v2: keep the fbc psr1 wa as it is - excluded from panel replay
Vinod Govindapillai (2):
d
> -Original Message-
> From: Intel-xe On Behalf Of Jouni
> Högander
> Sent: Friday, March 7, 2025 5:31 PM
> To: intel-gfx@lists.freedesktop.org; intel...@lists.freedesktop.org
> Cc: Hogander, Jouni
> Subject: [PATCH] drm/i915/psr: Check transcoder Selective Update support
> for PR as we
63 matches
Mail list logo
