Maintain two separate RB trees per order - one for clear (zeroed) blocks
and another for dirty (uncleared) blocks. This separation improves
code clarity and makes it more obvious which tree is being searched
during allocation. It also improves scalability and efficiency when
searching for a specifi
Am Wed, 3 Sep 2025 21:17:32 +0800
schrieb Zihuan Zhang :
> 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 in
Now with drm_writeback_connector moved to drm_connector it makes
more sense use drm_connector as an argument rather than drm_connector.
The writeback connector can easily be derived from drm_connector.
Signed-off-by: Suraj Kandpal
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_wb.c | 2 +-
...
== Series Details ==
Series: drm/i915/vrr: Hide even more ICL/TGL weirdness
URL : https://patchwork.freedesktop.org/series/154744/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_17237 -> Patchwork_154744v1
Summary
---
== Series Details ==
Series: drm/i915/display: Set SPREAD_AMP bit to enable SSC
URL : https://patchwork.freedesktop.org/series/154741/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_17237 -> Patchwork_154741v1
Summary
--
== Series Details ==
Series: drm/i915/dp: Work around a DSC pixel throughput issue
URL : https://patchwork.freedesktop.org/series/154736/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_17237 -> Patchwork_154736v1
Summary
---
From: Ville Syrjälä
Rename intel_vrr_flipline_offset() to intel_vrr_vmin_flipline_offset()
to better reflect the fact that it gives us the minimum offset allowed
between vmin and flipline.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_vrr.c | 8
1 file changed, 4
From: Ville Syrjälä
ICL/TGL VRR hardware won't allow us to program flipline==vmin. If we do
that the actual effect will be the same as if we had programmed
flipline=vmin+1, which would make the minimum vtotal one scanline taller
than expected.
To compensate for this we reduce vmin by one, and th
From: Ville Syrjälä
Previosuly we took care to hide most of the ICL/TGL vs. ADL+
differences. But the flipline>=vmin+1 stuff still remains.
Try to hide that as well.
Ville Syrjälä (2):
drm/i915/vrr: Hide the ICL/TGL intel_vrr_flipline_offset() mangling
better
drm/i915/vrr:
s/intel_vr
In the lack of better place to put it, Resizable BAR code has been
placed inside pci.c and setup-res.c that do not use it for anything.
Upcoming changes are going to add more Resizable BAR related API
functions to PCI core increasing the Resizable BAR code size from the
current.
As pci.c is huge f
We do not need a case switch to check cap_type_id in intel_vgpu_ioctl
for various reasons (it's impossible to hit the default case in the
current code, there's only one valid case to check, the error handling
code overlaps in both cases, etc.). Simplify the case switch into a
single if statement.
According to DP Specs[1]:
"SSC is enabled or disabled when the SPREAD_AMP bit in the
DOWNSPREAD_CTRL register is set or cleared (DPCD 00107h[4] = 1 or 0,
respectively)."
Set the SPREAD_AMP bit before starting link training to ensure SSC
is enabled as required.
[1]: DisplayPort Standard v2.1 - Se
Pass the DPCD sink/branch device descriptor along with the
is_branch/sink flag to intel_dp_get_dsc_sink_cap(). These will be used
by a follow up change to read out the branch device's DSC overall
throughput/line width capabilities and to detect a throughput/link-bpp
quirk.
Signed-off-by: Imre Deak
Read out the branch devices' maximum overall DSC pixel throughput and
line width and verify the mode's corresponding pixel clock and hactive
period against these.
Signed-off-by: Imre Deak
---
.../drm/i915/display/intel_display_types.h| 8 +++
drivers/gpu/drm/i915/display/intel_dp.c |
Some Synaptics MST branch devices have a problem decompressing a stream
with a compressed link-bpp higher than 12, if the pixel clock is higher
than ~50 % of the maximum throughput capability reported by the branch
device. The screen remains blank, or for some - mostly black content -
gets enabled,
Handle the DSC pixel throughput quirk, limiting the compressed link-bpp
value for Synaptics Panamera branch devices, working around a
blank/unstable output issue observed on docking stations containing
these branch devices, when using a mode with a high pixel clock and a
high compressed link-bpp va
Use the branch device's actual per-slice peak throughput to calculate
the minimum number of required DSC slices, falling back to the
hard-coded throughput values (as suggested by the DP Standard) if the
device's reported throughput value is 0.
For now use the minimum of the two throughput values,
This patchset works around an issue observed in docking stations
decompressing a DSC stream with a high pixel-clock and high compressed
link-bpp, resulting either in blank or unstable display output.
The affected devices all contain an older version of the Synaptics MST
branch device. The issue is
On Fri, 12 Sep 2025, Jani Nikula wrote:
Move the VLV clock related functions to their own file.
v2: Rebase
Signed-off-by: Jani Nikula
Reviewed-by: Michał Grzelak
BR,
Michał
Hi Dave and Sima,
Here goes a v2 of the drm-intel-next-2025-09-12 request.
The first one didn't get to the various mailing list because
of the very long diff.
This is exactly the same pull-request, but with fixed diff
history below. The backmerge in the middle got git confused,
but there's nothin
From: pengdonglin
Since commit a8bb74acd8efe ("rcu: Consolidate RCU-sched update-side function
definitions")
there is no difference between rcu_read_lock(), rcu_read_lock_bh() and
rcu_read_lock_sched() in terms of RCU read section and the relevant grace
period. That means that spin_lock(), which
== Series Details ==
Series: drm/i915/irq: clarify and refactor ->irq_mask (rev3)
URL : https://patchwork.freedesktop.org/series/154699/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_17233 -> Patchwork_154699v3
Summary
Hi Krzysztof
On Mon Sep 8, 2025 at 9:23 AM UTC, Krzysztof Karas wrote:
> Following the error path in that function may lead to usage of
> uninitialized struct i915_gem_ww_ctx object, so move call to
> i915_gem_ww_ctx_init() a bit earlier.
>
> Fixes: 15b6c9249870 ("drm/i915: Move i915_vma_lock in t
== Series Details ==
Series: drm/i915/irq: clarify and refactor ->irq_mask (rev2)
URL : https://patchwork.freedesktop.org/series/154699/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_17232 -> Patchwork_154699v2
Summary
Split ->irq_mask usage by platform, and move display related stuff under
display.
Jani Nikula (5):
drm/i915/irq: use a dedicated IMR cache for VLV/CHV
drm/i915/irq: use a dedicated IMR cache for gen 5-7
drm/i915/irq: rename irq_mask to gen2_imr_mask
drm/i915/irq: rename de_irq_mask[] to d
On Thu, 18 Sep 2025, Michał Grzelak wrote:
> Although I have just issued my r-b on the rest of the series, I would
> have one question. Can't we add on top of the series a separate commit
> with rename of vlv_get_cck_clock() into vlv_clock_get_cck()? It would
> be more consistent with the rest of
On Fri, 12 Sep 2025, Jani Nikula wrote:
Move towards VLV/CHV clock interfaces that handle sideband get/put
inside them instead of at the caller.
With this, we can switch to the simpler vlv_punit_get()/vlv_punit_put()
in vlv_get_cdclk().
We'll need to move vlv_init_gpll_ref_freq() outside of the
This code is in fact i915 driver core rather than display specific. Stop
using struct intel_display, and drop the dependency on display headers.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_fbdev_fb.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/dr
On 9/18/2025 2:04 AM, Ville Syrjala wrote:
From: Ville Syrjälä
While ICL/TGL VRR hardware doesn't have a register for the guardband
value, our lives will be simpler if we pretend that it does. Start
by computing the guardband the same as on ADL+ and storing it in
the state, and only then we c
On 9/18/2025 7:48 PM, Ville Syrjälä wrote:
On Thu, Sep 18, 2025 at 07:12:40PM +0530, Nautiyal, Ankit K wrote:
On 9/18/2025 5:44 PM, Ville Syrjälä wrote:
On Thu, Sep 18, 2025 at 03:03:02PM +0530, Nautiyal, Ankit K wrote:
On 9/18/2025 2:04 AM, Ville Syrjala wrote:
From: Ville Syrjälä
Current
On Thu, Sep 18, 2025 at 11:40:59AM +0300, Jani Nikula wrote:
> This code is in fact driver core rather than display specific. Pass
> struct drm_device instead of struct intel_display.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_fbdev.c
On Thu, Sep 18, 2025 at 11:40:56AM +0300, Jani Nikula wrote:
> Separate fbdev bo creation into a separate function
> intel_fbdev_fb_bo_create().
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/xe/display/intel_fbdev_fb.c | 33 ++---
> 1 file c
On Thu, Sep 18, 2025 at 11:41:00AM +0300, Jani Nikula wrote:
> This code is in fact i915 driver core rather than display specific. Stop
> using struct intel_display, and drop the dependency on display headers.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_fbdev_fb.c |
On Thu, Sep 18, 2025 at 11:40:55AM +0300, Jani Nikula wrote:
> Separate fbdev bo creation into a separate function
> intel_fbdev_fb_bo_create().
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_fbdev_fb.c | 33 +--
> drivers/
== Series Details ==
Series: drm/{i915,xe}/fbdev: refactor (rev2)
URL : https://patchwork.freedesktop.org/series/153980/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_17232 -> Patchwork_153980v2
Summary
---
**SUCCESS
On Thu, Sep 18, 2025 at 11:40:58AM +0300, Jani Nikula wrote:
> With the bo creation helper in place, we can lift
> intel_framebuffer_create() part to common code.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_fbdev.c| 31 +
On Thu, Sep 18, 2025 at 11:40:57AM +0300, Jani Nikula wrote:
> i915 and xe do different things on the failure path; i915 calls
> drm_gem_object_put() while xe calls xe_bo_unpin_map_no_vm(). Add a
> helper to enable further refactoring.
>
> v2: Call drm_gem_object_put() on intel_fbdev_fb_bo_destroy
On Thu, Sep 18, 2025 at 11:40:54AM +0300, Jani Nikula wrote:
> Pull struct drm_mode_fb_cmd2 initialization out of the driver dependent
> code into shared display code.
>
> v2: Rebase on xe stride alignment change
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/d
It's sketchy to pass error pointers via to_intel_framebuffer(). It
probably works as long as struct intel_framebuffer embeds struct
drm_framebuffer at offset 0, but be explicit about it.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_fbdev_fb.c | 7 +++
1 file changed, 7 i
This patchset converts all remaining cpufreq users to rely on the
__free(put_cpufreq_policy) annotation for policy references, instead of
calling cpufreq_cpu_put() manually.
Motivation:
- Reduce the chance of reference counting mistakes
- Make the code more consistent with the latest kernel style
On Thu, Sep 18, 2025 at 11:40:53AM +0300, Jani Nikula wrote:
> The function doesn't actually need struct drm_fb_helper for anything,
> just pass struct drm_device.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_fbdev.c| 2 +-
> driver
On Thu, Sep 18, 2025 at 11:40:52AM +0300, Jani Nikula wrote:
> It's sketchy to pass error pointers via to_intel_framebuffer(). It
> probably works as long as struct intel_framebuffer embeds struct
> drm_framebuffer at offset 0, but be explicit about it.
>
> Signed-off-by: Jani Nikula
Reviewed-by
On Thu, Sep 18, 2025 at 11:40:51AM +0300, Jani Nikula wrote:
> For reasons unknown, xe uses XE_PAGE_SIZE alignment for
> stride. Presumably it's just a confusion between stride alignment and bo
> allocation size alignment. Switch to 64 byte alignment to, uh, align
> with i915.
>
> This will also b
On Thu, Sep 18, 2025 at 03:25:47PM +0300, Jani Nikula wrote:
> Rename the struct intel_display de_irq_mask[] member to
> de_pipe_imr_mask[] to reflect its usage more accurately.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> .../gpu/drm/i915/display/intel_display_core.h
On Thu, Sep 18, 2025 at 03:25:46PM +0300, Jani Nikula wrote:
> Rename the struct drm_i915_private irq_mask member to gen2_imr_mask to
> reflect its usage more accurately.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/gt/gen2_engine_cs.c | 8
>
On Thu, Sep 18, 2025 at 03:25:45PM +0300, Jani Nikula wrote:
> There are three groups of platforms using i915->irq_mask independently:
> gen 2-4, VLV/CHV, and gen 5-7.
>
> The gen 5-7 usage is primarily limited to display. Move its irq_mask
> usage to struct intel_display as ilk_de_imr_mask for ge
On Thu, Sep 18, 2025 at 03:25:44PM +0300, Jani Nikula wrote:
> There are three groups of platforms using i915->irq_mask independently:
> gen 2-4, VLV/CHV, and gen 5-7.
>
> The VLV/CHV usage is purely limited to display. Move its irq_mask usage
> to struct intel_display as vlv_imr_mask for VLV/CHV.
On Thu, Sep 18, 2025 at 04:38:35PM +0300, Jani Nikula wrote:
> Abstract ilk_display_irq_reset(), moving display related reset
> there. This results in a slightly different order between GT and PCH
> reset, hopefully with no impact.
>
> v3: Reset display first (Ville)
>
> v2: Also move GEN7_ERR_IN
On Thu, Sep 18, 2025 at 03:07:20PM +0530, Nautiyal, Ankit K wrote:
>
> On 9/18/2025 2:04 AM, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > While ICL/TGL VRR hardware doesn't have a register for the guardband
> > value, our lives will be simpler if we pretend that it does. Start
> > by comp
Separate fbdev bo creation into a separate function
intel_fbdev_fb_bo_create().
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_fbdev_fb.c | 33 +--
drivers/gpu/drm/i915/display/intel_fbdev_fb.h | 1 +
2 files changed, 24 insertions(+), 10 deletions(-)
diff --
On 9/18/2025 5:44 PM, Ville Syrjälä wrote:
On Thu, Sep 18, 2025 at 03:03:02PM +0530, Nautiyal, Ankit K wrote:
On 9/18/2025 2:04 AM, Ville Syrjala wrote:
From: Ville Syrjälä
Currently our crtc_state->vrr.{vmin.vmax,flipline} are mangled on
TGL to account for the SCL delay (the hardware require
Abstract ilk_display_irq_reset(), moving display related reset
there. This results in a slightly different order between GT and PCH
reset, hopefully with no impact.
v3: Reset display first (Ville)
v2: Also move GEN7_ERR_INT (Ville)
Signed-off-by: Jani Nikula
---
.../gpu/drm/i915/display/intel_
There are three groups of platforms using i915->irq_mask independently:
gen 2-4, VLV/CHV, and gen 5-7.
The VLV/CHV usage is purely limited to display. Move its irq_mask usage
to struct intel_display as vlv_imr_mask for VLV/CHV.
vlv_imr_mask could be put inside a union with de_irq_mask[], but keep
== Series Details ==
Series: drm/1915: skl+ watermark/latency stuff (rev3)
URL : https://patchwork.freedesktop.org/series/154100/
State : failure
== Summary ==
Error: patch
https://patchwork.freedesktop.org/api/1.0/series/154100/revisions/3/mbox/ not
applied
Applying: drm/i915/dram: Also app
On Thu, Sep 18, 2025 at 07:12:40PM +0530, Nautiyal, Ankit K wrote:
>
> On 9/18/2025 5:44 PM, Ville Syrjälä wrote:
> > On Thu, Sep 18, 2025 at 03:03:02PM +0530, Nautiyal, Ankit K wrote:
> >> On 9/18/2025 2:04 AM, Ville Syrjala wrote:
> >>> From: Ville Syrjälä
> >>>
> >>> Currently our crtc_state->v
v2 of [1], unifying the stride alignment and error paths first, rebasing
the rest on top.
[1] https://lore.kernel.org/r/cover.1756931441.git.jani.nik...@intel.com
Jani Nikula (10):
drm/xe/fbdev: use the same 64-byte stride alignment as i915
drm/i915/fbdev: make intel_framebuffer_create() er
From: Ville Syrjälä
Move the inner loop out from the outer loop in
sanitize_wm_latency() to flatten things a bit.
Easier to read flat code.
v2: Move the inner loop out completely (Luca)
Cc: Luca Coelho
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/skl_watermark.c | 12 +--
On Fri, 12 Sep 2025, Jani Nikula wrote:
Use vlv_clock_get_hpll_vco() helper more to avoid looking at
i915->hpll_freq directly. Cache and return the cached results to avoid
repeated lookups.
v2: Rebase
Signed-off-by: Jani Nikula
Reviewed-by: Michał Grzelak
BR,
Michał
On Tue, Sep 16, 2025 at 01:29:17PM +0300, Luca Coelho wrote:
> On Fri, 2025-09-05 at 17:58 +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Some systems (eg. LNL Lenovo Thinkapd X1 Carbon) declare
> > semi-bogus non-monotonic WM latency values:
> > WM0 latency not provided
> > WM1 la
Hi Jani,
On Fri, 12 Sep 2025, Jani Nikula wrote:
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
On 9/18/2025 5:51 PM, Ville Syrjälä wrote:
On Thu, Sep 18, 2025 at 03:07:20PM +0530, Nautiyal, Ankit K wrote:
On 9/18/2025 2:04 AM, Ville Syrjala wrote:
From: Ville Syrjälä
While ICL/TGL VRR hardware doesn't have a register for the guardband
value, our lives will be simpler if we pretend th
On Thu, Sep 18, 2025 at 03:41:24PM +0300, Jani Nikula wrote:
> Abstract ilk_display_irq_reset(), moving display related reset
> there. This results in a slightly different order for the reset,
> hopefully with no impact.
>
> v2: Also move GEN7_ERR_INT (Ville)
>
> Signed-off-by: Jani Nikula
> ---
On Fri, 12 Sep 2025, Jani Nikula wrote:
With vlv_clock_get_czclk() caching the result on first use, we no longer
need a separate initializer. Remove intel_update_czclk() as
unnecessary. Log the CZCLK in vlv_clock_get_czclk() instead.
v2: Rebase
Signed-off-by: Jani Nikula
Reviewed-by: Michał
Hi Taotao,
Both patches merged to drm-intel-gt-next.
Thank you,
Andi
On Fri, Aug 22, 2025 at 03:06:59AM +, 陈涛涛 Taotao Chen wrote:
> From: Taotao Chen
>
> Without O_LARGEFILE, file->f_op->write_iter calls
> generic_write_check_limits(), which enforces a 2GB (MAX_NON_LFS) limit,
> causing -E
Hi Dave and Sima,
Here goes our drm-xe-fixes.
It has more fixes than normal for this time of the cycle,
but nothing very critical.
Perhaps the most critical one is the RCS/CCS yield policy
which prevents starvation in the CCS engine on BMG. A
patch that was slightly modified to add a missing incl
On Thu, 18 Sep 2025, Ville Syrjälä wrote:
> On Thu, Sep 18, 2025 at 03:41:24PM +0300, Jani Nikula wrote:
>> diff --git a/drivers/gpu/drm/i915/i915_irq.c
>> b/drivers/gpu/drm/i915/i915_irq.c
>> index ab65402bc6bf..af2b43679b1b 100644
>> --- a/drivers/gpu/drm/i915/i915_irq.c
>> +++ b/drivers/gpu/dr
Rename the struct drm_i915_private irq_mask member to gen2_imr_mask to
reflect its usage more accurately.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/gt/gen2_engine_cs.c | 8
drivers/gpu/drm/i915/i915_drv.h | 4 ++--
drivers/gpu/drm/i915/i915_irq.c | 16 +
On Thu, 18 Sep 2025, Ville Syrjälä wrote:
> On Thu, Sep 18, 2025 at 03:25:48PM +0300, Jani Nikula wrote:
>> -gen2_irq_reset(uncore, DE_IRQ_REGS);
>> -display->irq.ilk_de_imr_mask = ~0u;
>> -
>> if (GRAPHICS_VER(dev_priv) == 7)
>> intel_uncore_write(uncore, GEN7_ERR_INT, 0
Abstract ilk_display_irq_reset(), moving display related reset
there. This results in a slightly different order for the reset,
hopefully with no impact.
v2: Also move GEN7_ERR_INT (Ville)
Signed-off-by: Jani Nikula
---
.../gpu/drm/i915/display/intel_display_irq.c | 20 ++-
...
On Thu, Sep 18, 2025 at 03:25:48PM +0300, Jani Nikula wrote:
> Abstract ilk_display_irq_reset(), moving display related reset
> there. This results in a slightly different order for the reset,
> hopefully with no impact.
>
> Signed-off-by: Jani Nikula
> ---
> .../gpu/drm/i915/display/intel_displ
Rename the struct intel_display de_irq_mask[] member to
de_pipe_imr_mask[] to reflect its usage more accurately.
Signed-off-by: Jani Nikula
---
.../gpu/drm/i915/display/intel_display_core.h| 6 +-
drivers/gpu/drm/i915/display/intel_display_irq.c | 16
2 files changed, 1
There are three groups of platforms using i915->irq_mask independently:
gen 2-4, VLV/CHV, and gen 5-7.
The gen 5-7 usage is primarily limited to display. Move its irq_mask
usage to struct intel_display as ilk_de_imr_mask for gen 5-7.
ilk_de_imr_mask could be put inside a union with with vlv_imr_m
On Fri, 12 Sep 2025, Jani Nikula wrote:
Perhaps not the ideal place, but better than having to have the fields
in both struct drm_i915_private and struct xe_device.
v2: Rebase
Signed-off-by: Jani Nikula
Reviewed-by: Michał Grzelak
BR,
Michał
On Fri, 12 Sep 2025, Jani Nikula wrote:
The function has become so trivial it's no longer necessary. Inline it
at the call sites.
Signed-off-by: Jani Nikula
Reviewed-by: Michał Grzelak
BR,
Michał
Hi Jonathan,
> Jonathan Cavitt (2):
> drm/i915/gvt: Remove unnecessary check in reg_is_mmio
> drm/i915/gvt: Fix intel_vgpu_gpa_to_mmio_offset kernel docs
pushed to drm-intel-next.
Thank you,
Andi
On Fri, 12 Sep 2025, Jani Nikula wrote:
Move towards VLV/CHV clock interfaces that handle sideband get/put
inside them instead of at the caller.
We'll need to move the calls outside of existing get/put.
Suggested-by: Ville Syrjälä
Signed-off-by: Jani Nikula
Reviewed-by: Michał Grzelak
BR,
On 9/18/2025 2:04 AM, Ville Syrjala wrote:
From: Ville Syrjälä
While ICL/TGL VRR hardware doesn't have a register for the guardband
value, our lives will be simpler if we pretend that it does. Start
by computing the guardband the same as on ADL+ and storing it in
the state, and only then we c
On 9/18/2025 2:04 AM, Ville Syrjala wrote:
From: Ville Syrjälä
intel_vrr_fixed_rr_*() return values that have had the TGL
SCL adjustment applied to them. So we should indicate that these
values are only really useful when fed to the hardware. Add
a "_hw_" indicator to the function names to re
On 9/18/2025 2:04 AM, Ville Syrjala wrote:
From: Ville Syrjälä
In order to pretend that ICL/TGL VRR hardware has a similar guardband
as on ADL+ we'll need access to framestart_delay already during
intel_vrr_get_config(). Hoist the framestart_delay to an earlier point
to make that possible.
S
On 9/18/2025 2:04 AM, Ville Syrjala wrote:
From: Ville Syrjälä
I'd like to move towards a world where we can't more or less
pretend that the ICl/TGL VRR hardware works the same way as
ADL+. To that end extract some helpers to convert between
the guardband and pipeline_full representations.
S
On 9/18/2025 2:04 AM, Ville Syrjala wrote:
From: Ville Syrjälä
Currently our crtc_state->vrr.{vmin.vmax,flipline} are mangled on
TGL to account for the SCL delay (the hardware requires this mangling
or the actual vtotals will become incorrect).
Please correct me if I am wrong:
For display
On Wed, 17 Sep 2025, Ville Syrjälä wrote:
> On Wed, Sep 17, 2025 at 03:33:31PM +0300, Jani Nikula wrote:
>> On Thu, 04 Sep 2025, Ville Syrjälä wrote:
>> > On Wed, Sep 03, 2025 at 11:32:03PM +0300, Jani Nikula wrote:
>> >> xe does xe_bo_unpin_map_no_vm() on the failure path. Add a common helper
>>
This code is in fact driver core rather than display specific. Pass
struct drm_device instead of struct intel_display.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_fbdev.c| 2 +-
drivers/gpu/drm/i915/display/intel_fbdev_fb.c | 6 +++---
drivers/gpu/drm/i915/display/intel
On Tue, 16 Sep 2025, Ville Syrjälä wrote:
> For now I'd be happy if someone just nukes that bogus page alignemnt
> of the stride on xe, allowing i915 and xe to use the same code here.
I hope just [1] is enough for this.
[1]
https://lore.kernel.org/r/7f4972104de8b179d5724ae83892ee294d3f3fd3.1758
i915 and xe do different things on the failure path; i915 calls
drm_gem_object_put() while xe calls xe_bo_unpin_map_no_vm(). Add a
helper to enable further refactoring.
v2: Call drm_gem_object_put() on intel_fbdev_fb_bo_destroy()
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel
With the bo creation helper in place, we can lift
intel_framebuffer_create() part to common code.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_fbdev.c| 31 ++--
drivers/gpu/drm/i915/display/intel_fbdev_fb.c | 34 --
drivers/gpu/drm/i915/displa
Separate fbdev bo creation into a separate function
intel_fbdev_fb_bo_create().
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/xe/display/intel_fbdev_fb.c | 33 ++---
1 file changed, 23 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/xe/display/intel_fbdev_fb.c
b/dr
The function doesn't actually need struct drm_fb_helper for anything,
just pass struct drm_device.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_fbdev.c| 2 +-
drivers/gpu/drm/i915/display/intel_fbdev_fb.c | 10 +-
drivers/gpu/drm/i915/display/intel_fbdev_fb.h |
For reasons unknown, xe uses XE_PAGE_SIZE alignment for
stride. Presumably it's just a confusion between stride alignment and bo
allocation size alignment. Switch to 64 byte alignment to, uh, align
with i915.
This will also be helpful in deduplicating and unifying the xe and i915
framebuffer alloc
Hi,
Here's this week drm-misc-fixes PR.
Maxime
drm-misc-fixes-2025-09-18:
One fix for a documentation warning, a null pointer dereference fix for
anx7625, and a mutex unlock fix for cdns-mhdp8546
The following changes since commit 87b90cee22d8658a69c0fbd43633839b75f8f05f:
MAINTAINERS: drm-mis
On Wed, 17 Sep 2025, Ville Syrjälä wrote:
> On Wed, Sep 17, 2025 at 04:52:00PM +0300, Jani Nikula wrote:
>> The caching at the initial read is a bit fragile in case, say, a further
>> refactoring starts reading the frequencies at a time where it's not
>> possible. Add a note about it.
>>
>> Sugge
91 matches
Mail list logo
