On Thu, 2025-02-13 at 08:47 +0200, Jouni Högander wrote:
> This patch set is doing necessary modifications to support PSR update
> using DSB on LunarLake onwards
>
> It is not necessary to wait for PSR1 to idle or PSR2 to exit DEEP
> sleep at the begin of commit This is left out from DSB commit. T
On Fri, 2025-02-14 at 04:27 +, Kandpal, Suraj wrote:
>
>
> > -Original Message-
> > From: Intel-xe On Behalf
> > Of Jouni
> > Högander
> > Sent: Thursday, February 13, 2025 4:46 PM
> > To: intel-gfx@lists.freedesktop.org; intel...@lists.freedesktop.org
> > Cc: Hogander, Jouni
> > Su
> -Original Message-
> From: Murthy, Arun R
> Sent: Tuesday, January 28, 2025 9:21 PM
> To: intel...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org
> Cc: Kandpal, Suraj ; dmitry.barysh...@linaro.org;
> Murthy, Arun R
> Subject: [PATCH v8 01/14
> -Original Message-
> From: Intel-xe On Behalf Of Jouni
> Högander
> Sent: Thursday, February 13, 2025 4:46 PM
> To: intel-gfx@lists.freedesktop.org; intel...@lists.freedesktop.org
> Cc: Hogander, Jouni
> Subject: [PATCH] drm/i915/psr: Fix drm_WARN_ON in intel_psr_disable
>
> Currentl
== Series Details ==
Series: drm/i915/gt: Replace kmap with its safer kmap_local_page counterpart
(rev2)
URL : https://patchwork.freedesktop.org/series/143379/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_16131 -> Patchwork_143379v2
==
== Series Details ==
Series: drm/i915/gt: Replace kmap with its safer kmap_local_page counterpart
(rev2)
URL : https://patchwork.freedesktop.org/series/143379/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately
kmap_local_page(), unlike kmap(), performs a contextualized
mapping of pages. This means the pages are mapped locally to the
thread that created them, making them invisible outside the
thread and safer to use.
Replace kmap() and kunmap() with kmap_local_page() and
kunmap_local() counterparts for i
On Thu, 2025-01-16 at 19:47 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Hook up the display fault irq handlers for VLV/CHV.
>
> Unfortunately the actual hardware doesn't agree with the
> spec on how DPINVGTT should behave. The docs claim that
> the status bits can be cleared by writing
On Thu, 2025-01-16 at 19:47 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Make life a bit more straightforward by removing the bitwise
> not from {i9xx,i965}_error_mask() and instead do it when feeding
> the value to gen2_error_init(). Make life a bit easier I think.
>
> Signed-off-by: V
On Thu, 2025-01-16 at 19:47 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Introduce i915_error_regs as the EIR/EMR counterpart
> to the IIR/IMR/IER i915_irq_regs, and update the irq
> reset/postingstall to utilize them accordingly.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/d
On Thu, 2025-02-13 at 22:09 +0200, Govindapillai, Vinod wrote:
> On Thu, 2025-01-16 at 19:47 +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Hook up display GTT fault interrupts for ILK/SNB.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > .../gpu/drm/i915/display/intel_display_irq
On Thu, 2025-01-16 at 19:47 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Hook up display GTT fault interrupts for ILK/SNB.
>
> Signed-off-by: Ville Syrjälä
> ---
> .../gpu/drm/i915/display/intel_display_irq.c | 56 ++-
> drivers/gpu/drm/i915/i915_reg.h |
On Thu, 2025-01-16 at 19:47 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Dump out the display fault information from the IVB/HSW
> error interrupt handler.
>
> Signed-off-by: Ville Syrjälä
> ---
> .../gpu/drm/i915/display/intel_display_irq.c | 47 +++
> drivers/gpu/dr
On Thu, 13 Feb 2025, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Move intel_fb_xy_to_linear() and intel_add_fb_offsets()
> These are technially sitting somewhere between plane vs. fb code,
> but we do have a bunch of code like that in intel_fb.c anyway.
> Might need to think about splitting in
On Thu, 2025-01-16 at 19:47 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Decode the display faults a bit more extensively so that one
> doesn't have translate the bitmask to planes/etc. manually.
> Also for plane faults we can read out a bit of state from the
> relevant plane(s) and dump
On Thu, 13 Feb 2025, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Use the canonical 'plane_state' name for funciton arguments where
> appropriate.
*function
Reviewed-by: Jani Nikula
>
> Also do the s/int plane/int color_plane/ in couple of the
> function prototypes while at it.
>
> Signed-o
On Thu, 13 Feb 2025, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Move intel_{rotation,remapped}_info_size() into intel_fb.c as
> that seems a slightly better place than intel_display.c. I suppose
> these should live somewhere outside the display code as they are
> also used by the gem code.
>
On Thu, 13 Feb 2025, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Relocate intel_plane_uses_fence() into intel_fb.c. Not sure
> that's the best place, but since this is mostly about the
> fb and vma I can't think of anything truly better right now.
Better than intel_display.c anyway.
Reviewed
On Thu, 13 Feb 2025, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Currently vlv_wait_port_ready() takes the display+dig_port,
> but all it really needs is the encoder. The display can be
> dug out from therein.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/d
On Thu, 13 Feb 2025, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> While vlv_wait_port_ready() doens't directly talk to the VLV/CHV
> DPIO PHY, the signals it's looking for do come from the PHY. So
> it seems appropriate to relocate it into intel_dpio_phy.c.
>
> Signed-off-by: Ville Syrjälä
Re
On Thu, 13 Feb 2025, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> intel_atomic_plane.c (should rename it really) has become our
> standard place for generic plane code. Move intel_plane_destroy()
> there so it doesn't clutter intel_display.c.
>
> Signed-off-by: Ville Syrjälä
Agreed on the ren
On Thu, 13 Feb 2025, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The name of intel_hpd_poll_fini() suggests that it should live
> in intel_hotplug.c. Make it so.
>
> Signed-off-by: Ville Syrjälä
Side note, I've got patches convert all the hotplug and display irq code
over to struct intel_dis
On Thu, 13 Feb 2025, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Hide the annoying HDCP implementation details better by
> providing a intel_hdcp_cancel_works().
>
> Signed-off-by: Ville Syrjälä
Somehow the "cancel works" reads funny to me, but it's accurate.
Reviewed-by: Jani Nikula
> --
On Thu, 13 Feb 2025, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Hide the implementation details of the modeset retry work
> better.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_connector.c | 6 ++
> drivers/gpu/drm/i915/display/intel_display.c | 4 ++--
>
On Thu, 13 Feb 2025, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Hide the implementation details of the modeset retry work
> better.
>
> Signed-off-by: Ville Syrjälä
With the declaration moved from patch 1 to here,
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_conne
On Thu, 13 Feb 2025, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Since we have all the necessary bits in intel_connector.c might
> as well always initialize the modeset_retry_work for every connector.
> Avoids yet another init function you have to remember to call.
>
> Signed-off-by: Ville Syr
On Thu, 13 Feb 2025, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Most the modeset retry stuff look to be entirely generic, and
Nitpick, Most of... looks...
> so there doesn't seem to any reason to keep it in intel_dp.c.
> Move the generic bits into intel_connector.c.
>
> Signed-off-by: Ville
Hi Krzysztof,
On Thu, Jan 16, 2025 at 10:40:46AM +, Krzysztof Karas wrote:
> spin_lock/unlock() functions used in interrupt contexts could
> result in a deadlock, as seen in GitLab issue #13399:
> https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13399,
I moved this link in the tag sect
> -Original Message-
> From: Mike Rapoport
> Sent: Wednesday, February 12, 2025 12:15 PM
> To: Borah, Chaitanya Kumar
> Cc: intel-gfx@lists.freedesktop.org; intel...@lists.freedesktop.org; Saarinen,
> Jani ; Kurmi, Suresh Kumar
> ; x...@kernel.org; De Marchi, Lucas
>
> Subject: Re: Re
Hi Dave and Sima,
Here goes the xe fixes for this round.
Thanks,
Rodrigo.
drm-xe-fixes-2025-02-13:
- Remove bo->clients out of bos_lock area (Tejas)
- Carve out wopcm portion from the stolen memory (Nirmoy)
The following changes since commit a64dcfb451e254085a7daee5fe51bf22959d52d3:
Linux 6.1
Hi Dave and Sima,
Here goes the i915 fixes for this round, with only one
patch from Krzysztof on selftests.
drm-intel-fixes-2025-02-13:
- Selftest fix: avoid using uninitialized context
The following changes since commit a64dcfb451e254085a7daee5fe51bf22959d52d3:
Linux 6.14-rc2 (2025-02-09 12:4
Hi Markus,
On Tue, Feb 11, 2025 at 07:33:30AM +0100, Markus Theil wrote:
> This is part of a prandom cleanup, which removes
> next_pseudo_random32 and replaces it with the standard PRNG.
>
> Signed-off-by: Markus Theil
I merged just this patch in drm-intel-gt-next.
Thanks,
Andi
On Wed, Feb 12, 2025 at 01:25:05PM -0500, Rodrigo Vivi wrote:
> On Wed, Feb 12, 2025 at 08:57:10AM +0200, Raag Jadav wrote:
> > On Tue, Feb 04, 2025 at 12:35:23PM +0530, Raag Jadav wrote:
> > > This series introduces device wedged event in DRM subsystem and uses it
> > > in xe, i915 and amdgpu driv
On Thu, Feb 13, 2025 at 03:33:08PM +0100, Krzysztof Niemiec wrote:
On 2025-02-12 at 16:35:16 GMT, Andi Shyti wrote:
Hi Krzysztof,
On Wed, Feb 12, 2025 at 12:50:17PM +0100, Krzysztof Niemiec wrote:
> On 2025-02-10 at 14:01:19 GMT, Andi Shyti wrote:
> > On Thu, Feb 06, 2025 at 07:07:38PM +0100, J
== Series Details ==
Series: drm/i915: Hoist some stuff out from intel_display.c
URL : https://patchwork.freedesktop.org/series/144803/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_16126 -> Patchwork_144803v1
Summary
-
Hi,
Here's this week drm-misc-fixes PR
Maxime
drm-misc-fixes-2025-02-13:
Some locking fixes for the HDMI infrastructure tests, an unitialized
mutex fix for host1x, an unitialized variable fix for panthor, and a
config selection fix for hibmc.
The following changes since commit 2c1ed907520c50326b
On 2025-02-13 9:28 a.m., Tvrtko Ursulin wrote:
>
> On 13/02/2025 13:36, Liang, Kan wrote:
>> On 2025-02-12 11:13 p.m., Lucas De Marchi wrote:
>>> On Tue, Jan 21, 2025 at 12:19:15PM -0500, Liang, Kan wrote:
On 2025-01-21 11:59 a.m., Lucas De Marchi wrote:
> On Tue, Jan 21, 202
== Series Details ==
Series: drm/i915: Hoist some stuff out from intel_display.c
URL : https://patchwork.freedesktop.org/series/144803/
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
== Series Details ==
Series: drm/i915: Hoist some stuff out from intel_display.c
URL : https://patchwork.freedesktop.org/series/144803/
State : warning
== Summary ==
Error: dim checkpatch failed
982b141eeb11 drm/i915: Move modeset_retry stuff into intel_connector.c
57a7a8efd3d5 drm/i915: Alway
From: Ville Syrjälä
Relocate intel_plane_uses_fence() into intel_fb.c. Not sure
that's the best place, but since this is mostly about the
fb and vma I can't think of anything truly better right now.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 10 --
From: Ville Syrjälä
intel_atomic_plane.c (should rename it really) has become our
standard place for generic plane code. Move intel_plane_destroy()
there so it doesn't clutter intel_display.c.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_atomic_plane.c | 13 +
From: Ville Syrjälä
Hide the annoying HDCP implementation details better by
providing a intel_hdcp_cancel_works().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 6 ++
drivers/gpu/drm/i915/display/intel_hdcp.c| 9 +
drivers/gpu/drm/i915/display/
From: Ville Syrjälä
Move intel_fb_xy_to_linear() and intel_add_fb_offsets()
These are technially sitting somewhere between plane vs. fb code,
but we do have a bunch of code like that in intel_fb.c anyway.
Might need to think about splitting intel_fb.c into pure fb vs.
plane->fb related stuff some
From: Ville Syrjälä
The name of intel_hpd_poll_fini() suggests that it should live
in intel_hotplug.c. Make it so.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 16
drivers/gpu/drm/i915/display/intel_display.h | 2 --
drivers/gpu/drm/i915/dis
From: Ville Syrjälä
Use the canonical 'plane_state' name for funciton arguments where
appropriate.
Also do the s/int plane/int color_plane/ in couple of the
function prototypes while at it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fb.c | 32 -
From: Ville Syrjälä
Move intel_{rotation,remapped}_info_size() into intel_fb.c as
that seems a slightly better place than intel_display.c. I suppose
these should live somewhere outside the display code as they are
also used by the gem code.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915
From: Ville Syrjälä
Currently vlv_wait_port_ready() takes the display+dig_port,
but all it really needs is the encoder. The display can be
dug out from therein.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/g4x_dp.c | 2 +-
drivers/gpu/drm/i915/display/g4x_hdmi.c
From: Ville Syrjälä
While vlv_wait_port_ready() doens't directly talk to the VLV/CHV
DPIO PHY, the signals it's looking for do come from the PHY. So
it seems appropriate to relocate it into intel_dpio_phy.c.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 34 --
From: Ville Syrjälä
Since we have all the necessary bits in intel_connector.c might
as well always initialize the modeset_retry_work for every connector.
Avoids yet another init function you have to remember to call.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_connector
From: Ville Syrjälä
Most the modeset retry stuff look to be entirely generic, and
so there doesn't seem to any reason to keep it in intel_dp.c.
Move the generic bits into intel_connector.c.
Signed-off-by: Ville Syrjälä
---
.../gpu/drm/i915/display/intel_connector.c| 39
..
From: Ville Syrjälä
Hide the implementation details of the modeset retry work
better.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_connector.c | 6 ++
drivers/gpu/drm/i915/display/intel_display.c | 4 ++--
2 files changed, 8 insertions(+), 2 deletions(-)
diff --gi
From: Ville Syrjälä
intel_display.c still has a bunch of random stuff in it.
Move some of it into a slightly better place.
Ville Syrjälä (12):
drm/i915: Move modeset_retry stuff into intel_connector.c
drm/i915: Always initialize connector->modeset_retry_work
drm/i915: Extract intel_connect
On 2025-02-12 at 16:35:16 GMT, Andi Shyti wrote:
> Hi Krzysztof,
>
> On Wed, Feb 12, 2025 at 12:50:17PM +0100, Krzysztof Niemiec wrote:
> > On 2025-02-10 at 14:01:19 GMT, Andi Shyti wrote:
> > > On Thu, Feb 06, 2025 at 07:07:38PM +0100, Janusz Krzysztofik wrote:
> > > > We return immediately from
On 13/02/2025 13:36, Liang, Kan wrote:
On 2025-02-12 11:13 p.m., Lucas De Marchi wrote:
On Tue, Jan 21, 2025 at 12:19:15PM -0500, Liang, Kan wrote:
On 2025-01-21 11:59 a.m., Lucas De Marchi wrote:
On Tue, Jan 21, 2025 at 10:53:31AM -0500, Liang, Kan wrote:
On 2025-01-21 9:29 a.m., Lucas
Hi Markus,
> next_pseudo_random32 implements a LCG with known bad statistical
> properties and is only used in two pieces of testing code. Remove and
> convert the remaining two users to the single PRNG interface in
> prandom.h
>
> This removes another option of using an insecure PRNG.
>
> Marku
== Series Details ==
Series: drm/i915/fbc: FBC Dirty rect feature support (rev2)
URL : https://patchwork.freedesktop.org/series/144725/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_16126 -> Patchwork_144725v2
Summary
-
On Thu, Feb 13, 2025 at 03:25:57PM +0200, Vinod Govindapillai wrote:
> Dirty rectangle feature allows FBC to recompress a subsection
> of a frame. When this feature is enabled, display will read
> the scan lines between dirty rectangle start line and dirty
> rectangle end line in subsequent frames.
== Series Details ==
Series: drm/i915/fbc: FBC Dirty rect feature support (rev2)
URL : https://patchwork.freedesktop.org/series/144725/
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/fbc: FBC Dirty rect feature support (rev2)
URL : https://patchwork.freedesktop.org/series/144725/
State : warning
== Summary ==
Error: dim checkpatch failed
dfecd31fc71c drm/damage-helper: add const qualifier in
drm_atomic_helper_damage_merged()
bb0f4d140
It is not recommended to have both FBC dirty rect and PSR2
selective fetch be enabled at the same time. Mark FBC as not
possible, if PSR2 selective fetch is enabled.
v2: fix the condition to disable FBC if PSR2 enabled (Jani)
v3: use HAS_FBC_DIRTY_RECT()
v4: Update to patch description
Bspec: 6
On 2025-02-12 11:13 p.m., Lucas De Marchi wrote:
> On Tue, Jan 21, 2025 at 12:19:15PM -0500, Liang, Kan wrote:
>>
>>
>> On 2025-01-21 11:59 a.m., Lucas De Marchi wrote:
>>> On Tue, Jan 21, 2025 at 10:53:31AM -0500, Liang, Kan wrote:
On 2025-01-21 9:29 a.m., Lucas De Marchi wrote:
Register definitions for FBC dirty rect support
v2: - update to the patch subject
Bspec: 71675, 73424
Signed-off-by: Vinod Govindapillai
---
drivers/gpu/drm/i915/display/intel_fbc_regs.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc_regs.h
If FBC is already active, we don't need to call FBC activate
routine again unless there are changes to the fences. So skip
this on all platforms that don't have fences. Any FBC register
updates done after enabling the dirty rect support in xe3 will
trigger nuke by FBC which is counter productive to
Dirty rectangle feature allows FBC to recompress a subsection
of a frame. When this feature is enabled, display will read
the scan lines between dirty rectangle start line and dirty
rectangle end line in subsequent frames.
Use the merged damage clip stored in the plane state to
configure the FBC d
Userspace can pass damage area clips per plane to track
changes in a plane and some display components can utilze
these damage clips for efficiently handling use cases like
FBC, PSR etc. A merged damage area is generated and its
coordinates are updated relative to viewport and HW and
stored in the
Introduce a macro to check if the platform supports FBC dirty
rect capability.
v2: - update to the patch subject
Signed-off-by: Vinod Govindapillai
---
drivers/gpu/drm/i915/display/intel_display_device.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/display/intel_disp
Add a const qualifier for the "state" parameter as well as we could
use this helper to get the combined damage in cases of const
drm_plane_state as well. Needed mainly for xe driver big joiner cases
where we need to track the damage from immutable plane state.
Signed-off-by: Vinod Govindapillai
-
Dirty rect support for FBC in xe3 onwards based on the comments after the
initial RFC series.
v2: Dirty rect related compute and storage moved to fbc state (Ville)
V3: Dont call fbc activate if FBC is already active
v4: Dirty rect compute and programming moved within DSB scope
New changes ar
== Series Details ==
Series: drm/i915/psr: Fix drm_WARN_ON in intel_psr_disable
URL : https://patchwork.freedesktop.org/series/144788/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_16126 -> Patchwork_144788v1
Summary
--
== Series Details ==
Series: drm/i915: Add drm_panic support (rev4)
URL : https://patchwork.freedesktop.org/series/141935/
State : failure
== Summary ==
Error: patch
https://patchwork.freedesktop.org/api/1.0/series/141935/revisions/4/mbox/ not
applied
Applying: drm/i915/fbdev: Add intel_fbde
On Alderlake and later, it's not possible to disable tiling when DPT
is enabled.
So this commit implements Y-Tiling support, to still be able to draw
the panic screen.
Signed-off-by: Jocelyn Falempe
---
.../gpu/drm/i915/display/intel_atomic_plane.c | 70 +--
.../drm/i915/display/
On Alderlake and later, it's not possible to disable tiling when DPT
is enabled.
So this commit implements 4-Tiling support, to still be able to draw
the panic screen.
Signed-off-by: Jocelyn Falempe
---
.../gpu/drm/i915/display/intel_atomic_plane.c | 22 ++-
1 file changed, 21 in
This adds drm_panic support for a wide range of Intel GPU. I've
tested it only on 3 laptops, Haswell (with 128MB of eDRAM),
Comet Lake, and Lunar Lake.
For hardware using DPT, it's not possible to disable tiling, as you
will need to reconfigure the way the GPU is accessing the
framebuffer.
Signed-
drm_panic draws in linear framebuffer, so it's easier to re-use the
current framebuffer, and disable tiling in the panic handler, to show
the panic screen.
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/i915/display/i9xx_plane.c | 23 +++
.../drm/i915/display/intel_displa
On Lunar Lake, if the panic occurs when fbcon is active, the panic
screen is only partially visible on the screen. Adding this
intel_frontbuffer_flush() call solves the issue.
It's probably not safe to do that in the panic handler, but that's
still better than nothing.
Signed-off-by: Jocelyn Falem
drm_panic draws in linear framebuffer, so it's easier to re-use the
current framebuffer, and disable tiling in the panic handler, to show
the panic screen.
Signed-off-by: Jocelyn Falempe
---
.../drm/i915/display/skl_universal_plane.c| 20 +++
1 file changed, 20 insertions(+)
Prepare the work for drm_panic support. This is used to map the
current framebuffer, so the CPU can overwrite it with the panic
message.
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/i915/display/intel_bo.c| 10 +
drivers/gpu/drm/i915/display/intel_bo.h| 2 ++
drivers/gpu/d
The vaddr of the fbdev framebuffer is private to the struct
intel_fbdev, so this function is needed to access it for drm_panic.
Also the struct i915_vma is different between i915 and xe, so it
requires a few functions to access fbdev->vma->iomap.
Signed-off-by: Jocelyn Falempe
---
v2:
* Add in
This is a draft of drm_panic support for i915.
I've tested it on the 4 intel laptops I have at my disposal.
* Haswell with 128MB of eDRAM.
* Comet Lake.
* Alder Lake (with DPT, and Y-tiling).
* Lunar Lake (with DPT, and 4-tiling, and using the Xe driver.
I tested panic in both fbdev console a
On Thu, 13 Feb 2025, "Kandpal, Suraj" wrote:
>> @@ -1941,12 +1942,13 @@ static enum drm_mode_status
>> intel_sdvo_mode_valid(struct drm_connector *connector,
>> const struct drm_display_mode *mode) {
>> + struct intel_display *display = to_intel_display(connector->dev);
>
Currently intel_psr_disable is dumping out warning if PSR is not
supported. On monitor supporting only Panel Replay we are seeing this
warning. Fix this by checking Panel Replay support as well.
Signed-off-by: Jouni Högander
---
drivers/gpu/drm/i915/display/intel_psr.c | 3 ++-
1 file changed, 2
On 2/13/2025 2:36 AM, Ville Syrjälä wrote:
On Mon, Feb 03, 2025 at 06:08:18PM +0530, Ankit Nautiyal wrote:
Fill vrr.mode during compute_config and update intel_vrr_get_config() to
read vrr.mode based on CMRR and VRR enable conditions.
This vrr.mode thing still feels like a bit of a distractio
== Series Details ==
Series: drm/i915/hdcp: Create force_hdcp14 debug fs entry (rev3)
URL : https://patchwork.freedesktop.org/series/144461/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_16126 -> Patchwork_144461v3
Summary
> -Original Message-
> From: Murthy, Arun R
> Sent: Wednesday, February 12, 2025 9:48 PM
> To: dri-de...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; intel-
> x...@lists.freedesktop.org
> Cc: Borah, Chaitanya Kumar ; Syrjala,
> Ville ; Murthy, Arun R
> Subject: [PATCH v5 2/3] d
> -Original Message-
> From: Nikula, Jani
> Sent: Thursday, February 13, 2025 2:43 PM
> To: Kandpal, Suraj ; intel-gfx@lists.freedesktop.org;
> intel...@lists.freedesktop.org
> Subject: RE: [PATCH 01/14] drm/i915/dp: convert g4x_dp.[ch] to struct intel
> display
>
> On Thu, 13 Feb 2025
> -Original Message-
> From: Intel-xe On Behalf Of Jani
> Nikula
> Sent: Wednesday, February 12, 2025 10:07 PM
> To: intel-gfx@lists.freedesktop.org; intel...@lists.freedesktop.org
> Cc: Nikula, Jani
> Subject: [PATCH 10/14] drm/i915/display: convert
> intel_mode_valid_max_plane_size()
> -Original Message-
> From: Intel-gfx On Behalf Of Jani
> Nikula
> Sent: Wednesday, February 12, 2025 10:07 PM
> To: intel-gfx@lists.freedesktop.org; intel...@lists.freedesktop.org
> Cc: Nikula, Jani
> Subject: [PATCH 09/14] drm/i915/display: convert
> intel_cpu_transcoder_mode_valid(
On Thu, 13 Feb 2025, "Kandpal, Suraj" wrote:
>> -Original Message-
>> From: Intel-gfx On Behalf Of Jani
>> Nikula
>> Sent: Wednesday, February 12, 2025 10:07 PM
>> To: intel-gfx@lists.freedesktop.org; intel...@lists.freedesktop.org
>> Cc: Nikula, Jani
>> Subject: [PATCH 02/14] drm/i915/h
> -Original Message-
> From: Intel-gfx On Behalf Of Jani
> Nikula
> Sent: Wednesday, February 12, 2025 10:07 PM
> To: intel-gfx@lists.freedesktop.org; intel...@lists.freedesktop.org
> Cc: Nikula, Jani
> Subject: [PATCH 08/14] drm/i915/sdvo: convert intel_sdvo.[ch] to struct
> intel_dis
On Thu, 13 Feb 2025, "Kandpal, Suraj" wrote:
>> -Original Message-
>> From: Intel-gfx On Behalf Of Jani
>> Nikula
>> Sent: Wednesday, February 12, 2025 10:07 PM
>> To: intel-gfx@lists.freedesktop.org; intel...@lists.freedesktop.org
>> Cc: Nikula, Jani
>> Subject: [PATCH 01/14] drm/i915/d
> -Original Message-
> From: Intel-xe On Behalf Of Jani
> Nikula
> Sent: Wednesday, February 12, 2025 10:07 PM
> To: intel-gfx@lists.freedesktop.org; intel...@lists.freedesktop.org
> Cc: Nikula, Jani
> Subject: [PATCH 07/14] drm/i915/display: convert intel_set_{cpu,
> pch}_fifo_underru
> -Original Message-
> From: Intel-xe On Behalf Of Jani
> Nikula
> Sent: Wednesday, February 12, 2025 10:07 PM
> To: intel-gfx@lists.freedesktop.org; intel...@lists.freedesktop.org
> Cc: Nikula, Jani
> Subject: [PATCH 06/14] drm/i915/hpd: drop dev_priv parameter from
> intel_hpd_pin_de
> -Original Message-
> From: Intel-gfx On Behalf Of Jani
> Nikula
> Sent: Wednesday, February 12, 2025 10:07 PM
> To: intel-gfx@lists.freedesktop.org; intel...@lists.freedesktop.org
> Cc: Nikula, Jani
> Subject: [PATCH 05/14] drm/i915/display: convert assert_port_valid() to
> struct in
> -Original Message-
> From: Intel-gfx On Behalf Of Jani
> Nikula
> Sent: Wednesday, February 12, 2025 10:07 PM
> To: intel-gfx@lists.freedesktop.org; intel...@lists.freedesktop.org
> Cc: Nikula, Jani
> Subject: [PATCH 04/14] drm/i915/display: convert assert_transcoder*() to
> struct i
> -Original Message-
> From: Intel-gfx On Behalf Of Jani
> Nikula
> Sent: Wednesday, February 12, 2025 10:07 PM
> To: intel-gfx@lists.freedesktop.org; intel...@lists.freedesktop.org
> Cc: Nikula, Jani
> Subject: [PATCH 03/14] drm/i915/ips: convert hsw_ips.c to struct
> intel_display
>
> -Original Message-
> From: Intel-gfx On Behalf Of Jani
> Nikula
> Sent: Wednesday, February 12, 2025 10:07 PM
> To: intel-gfx@lists.freedesktop.org; intel...@lists.freedesktop.org
> Cc: Nikula, Jani
> Subject: [PATCH 02/14] drm/i915/hdmi: convert g4x_hdmi.[ch] to struct
> intel_displ
> -Original Message-
> From: Intel-gfx On Behalf Of Jani
> Nikula
> Sent: Wednesday, February 12, 2025 10:07 PM
> To: intel-gfx@lists.freedesktop.org; intel...@lists.freedesktop.org
> Cc: Nikula, Jani
> Subject: [PATCH 01/14] drm/i915/dp: convert g4x_dp.[ch] to struct intel
> display
>
On Wed, Feb 12, 2025 at 06:46:40PM +0200, Jani Nikula wrote:
> On Wed, 12 Feb 2025, Imre Deak wrote:
> > Starting with DPCD version 2.0 bits 6:3 of the DP_DSC_BITS_PER_PIXEL_INC
> > DPCD register contains the NativeYCbCr422_MAX_bpp_DELTA field, which can
> > be non-zero as opposed to earlier DPCD
On Wed, 12 Feb 2025, Ville Syrjälä wrote:
> On Wed, Feb 12, 2025 at 06:36:29PM +0200, Jani Nikula wrote:
>> Convert a bunch of files and functions to struct intel display.
>>
>> The approach is to mostly convert a file, then see what the stragglers
>> are, convert those too, and repeat.
>>
>> Th
Testing HDCP 1.4 becomes tough since the only way our code comes to
HDCP 1.4 pathway is if the monitor only supports HDCP 1.4 which
becomes tough to find sometimes.
Setting this debug_fs entry will force use to use the HDCP 1.4 path
so that more robust HDCP 1.4 testing can take place.
--v2
-Move t
1 - 100 of 101 matches
Mail list logo
