On 9/12/2025 7:33 PM, Ville Syrjälä wrote:
On Thu, Sep 11, 2025 at 08:15:39AM +0530, Ankit Nautiyal wrote:
Instead of setting vrr.guardband to vblank, use optimal guardband that
works for most of the cases. This will help in avoiding need of change
in guardband and fix the LRR feature that nee
On 9/11/2025 8:07 PM, Ville Syrjälä wrote:
On Thu, Sep 11, 2025 at 08:15:53AM +0530, Ankit Nautiyal wrote:
Refactor intel_panel_highest_mode() to return the fixed mode with the
highest pixel clock, removing the fallback to the adjusted mode. This makes
the function semantics clearer and better
On 9/11/2025 8:11 PM, Ville Syrjälä wrote:
On Thu, Sep 11, 2025 at 08:15:54AM +0530, Ankit Nautiyal wrote:
With VRR timing generator always on, the fixed refresh rate is achieved
by setting vrr.flipline and vrr.vmax as the vtotal for the desired mode.
This creates a problem for seamless_mn dr
On 9/11/2025 7:44 PM, Ville Syrjälä wrote:
On Thu, Sep 11, 2025 at 08:15:45AM +0530, Ankit Nautiyal wrote:
Add a helper to compute vblank time needed for transmitting specific
DisplayPort SDPs like PPS, GAMUT_METADATA, and VSC_EXT. Latency is
based on line count per packet type and current lin
On 9/11/2025 7:31 PM, Ville Syrjälä wrote:
On Thu, Sep 11, 2025 at 08:15:44AM +0530, Ankit Nautiyal wrote:
Currently dsc/scaler prefill latencies are handled during watermark
calculations. With the optimized guardband, we need to compute the
latencies to find the minimum guardband that works f
On 9/11/2025 7:28 PM, Ville Syrjälä wrote:
On Thu, Sep 11, 2025 at 08:15:42AM +0530, Ankit Nautiyal wrote:
Refactor dsc_prefill_latency and scaler_prefill_latency to take
linetime as an explicit parameter instead of computing it internally.
This avoids redundant calculations and simplifies sc
On 9/11/2025 7:55 PM, Ville Syrjälä wrote:
On Thu, Sep 11, 2025 at 08:15:50AM +0530, Ankit Nautiyal wrote:
When VRR TG is always enabled and an optimized guardband is used, the pipe
vblank start is derived from the guardband.
Currently TRANS_SET_CONTEXT_LATENCY is programmed with crtc_vblank_s
On Tue, Sep 09, 2025 at 08:32:11PM +0530, Nautiyal, Ankit K wrote:
>
> On 9/8/2025 10:13 PM, Ville Syrjälä wrote:
> > On Sun, Sep 07, 2025 at 01:02:39PM +0530, Ankit Nautiyal wrote:
> >> In the current VRR implementation, vrr.vmin and vrr.guardband are set such
> >> that they do not need to change
On Fri, Aug 29, 2025 at 03:17:02PM +0200, Maarten Lankhorst wrote:
> drm_crtc_accurate_vblank_count takes a spinlock, which we should avoid
> in tracepoints and debug functions.
>
> This also prevents taking the spinlock 2x during the critical
> section of pipe updates for DSI updates.
>
> Signed
> -Original Message-
> From: Jani Nikula
> Sent: Friday, September 12, 2025 1:52 PM
> To: Bhadane, Dnyaneshwar ; intel-
> x...@lists.freedesktop.org
> Cc: Bhadane, Dnyaneshwar
> Subject: Re: [PATCH 2/3] drm/i915/display: Add definition for wcl as
> subplatform
>
> On Fri, 12 Sep 2025,
On Wed, 3 Sep 2025 21:17:26 +0800
Zihuan Zhang wrote:
> Replace the manual cpufreq_cpu_put() with __free(put_cpufreq_policy)
> annotation for policy references. This reduces the risk of reference
> counting mistakes and aligns the code with the latest kernel style.
>
> No functional change inte
On 9/8/25 5:53 AM, David Hildenbrand wrote:
On 08.09.25 14:25, Lorenzo Stoakes wrote:
On Sat, Sep 06, 2025 at 08:56:48AM +0200, David Hildenbrand wrote:
On 06.09.25 03:05, John Hubbard wrote:
...
Roughly, what I am thinking (limiting it to pte+pmd case) about is
the following:
I cannot get
Introduce a helper to compute the max link wake latency when using
Auxless/Aux wake mechanism for PSR/Panel Replay/LOBF features.
This will be used to compute the minimum guardband so that the link wake
latencies are accounted and these features work smoothly for higher
refresh rate panels.
Bspec
Hi,
Here are some initial clean-ups and small refactoring in preparation
for further refactoring of the watermark code.
Please review.
Cheers,
Luca.
Luca Coelho (6):
drm/i915/wm: clarify watermark ops with comments
drm/i915/wm: move intel_sagv_init() to avoid forward declaration
drm/i915
This is v2 of [1]. There were issues with sideband get/put, discovered
in CI, so I ended up doing what Ville suggested in [2], and handling
sideband get/put inside the functions. This is done in new patches 1-2,
which obviously caused some rebase churn in the rest. I also removed
vlv_get_cck_clock_
== Series Details ==
Series: drm: Miscellaneous fixes in drm code
URL : https://patchwork.freedesktop.org/series/154173/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_17150 -> Patchwork_154173v1
Summary
---
**FAILURE
Fixes the comment about the driver-initiated FLR to refer to
the 'xe' driver instead of the old 'i915' driver.
Signed-off-by: Varun Gupta
---
drivers/gpu/drm/xe/xe_device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/xe/xe_device.c b/drivers/gpu/drm/xe/xe_
On 08.09.25 17:16, Mark Brown wrote:
On Mon, Sep 01, 2025 at 05:03:40PM +0200, David Hildenbrand wrote:
We can just cleanup the code by calculating the #refs earlier,
so we can just inline what remains of record_subpages().
Calculate the number of references/pages ahead of times, and record the
To support PXP, i915 needs to interface with CSME, which is done via the
component interface. However, BIOS/Coreboot can hide the CSME device,
which leads to i915 timing out waiting for the component to bind. While
PXP failing to initialize is a supported scenario (and there are several
possible wa
19 matches
Mail list logo
