From: Ville Syrjälä
drm_client_firmware_config() is currently picking up the current
mode of the crtc via the legacy crtc->mode, which is not supposed
to be used by atomic drivers at all. We can't simply switch over
to the proper crtc->state->mode because we drop the crtc->mutex
(which protects c
On Fri, Feb 28, 2025 at 06:54:12PM -0300, André Almeida wrote:
> Hi Raag,
>
> On 2/28/25 11:20, Raag Jadav wrote:
> > Cc: Lucas
> >
> > On Fri, Feb 28, 2025 at 09:13:52AM -0300, André Almeida wrote:
> > > When a device get wedged, it might be caused by a guilty application.
> > > For userspace, k
From: Ville Syrjälä
Rename the 'new_crtc' variable to just 'crtc' in
drm_client_firmware_config(). We don't call any of the other
stuff in here new or old so this feels out of place.
v2: Rebase
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_client_modeset.c | 12 ++--
1 file cha
Hi Ville,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-exynos/exynos-drm-next]
[also build test ERROR on linus/master v6.14-rc4 next-20250228]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to
From: Ville Syrjälä
The most interesting part is the change to modes[] to solve
the lifetime issue so that we can stop using the legacy
crtc->mode for atomic drivers.
Additionally I included a bunch of cleanups, some of which were
inherited from https://patchwork.freedesktop.org/series/132051/
== Series Details ==
Series: drm/client: Stop using legacy crtc->mode and a bunch of cleanups (rev5)
URL : https://patchwork.freedesktop.org/series/139493/
State : warning
== Summary ==
Error: dim checkpatch failed
c9317d69de4f drm/client: Constify modes
3d8b274336b8 drm/client: Use array nota
Hi Raag,
On 2/28/25 11:58, Raag Jadav wrote:
On Fri, Feb 28, 2025 at 09:13:53AM -0300, André Almeida wrote:
To notify userspace about which app (if any) made the device get in a
wedge state, make use of drm_wedge_app_info parameter, filling it with
the app PID and name.
Signed-off-by: André Al
== Series Details ==
Series: drm/client: Stop using legacy crtc->mode and a bunch of cleanups (rev5)
URL : https://patchwork.freedesktop.org/series/139493/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_16205 -> Patchwork_139493v5
===
Hi Raag,
On 2/28/25 11:20, Raag Jadav wrote:
Cc: Lucas
On Fri, Feb 28, 2025 at 09:13:52AM -0300, André Almeida wrote:
When a device get wedged, it might be caused by a guilty application.
For userspace, knowing which app was the cause can be useful for some
situations, like for implementing a
From: Ville Syrjälä
Replace the 'unsigned int i' footguns with plain old signed
int. Avoids accidents if/when someone decides they need
to iterate backwards.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_client_modeset.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff
On Thu, Feb 20, 2025 at 10:53:57AM +0100, Simona Vetter wrote:
> On Wed, Feb 19, 2025 at 06:02:39PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Video players (eg. mpv) do periodic XResetScreenSaver() calls to
> > keep the screen on while the video playing. The modesetting ddx
> >
From: Ville Syrjälä
crtc->mode is legacy junk and shouldn't really be used with
atomic drivers.
Most (all?) atomic drivers do end up still calling
drm_atomic_helper_update_legacy_modeset_state() at some
point, so crtc->mode does still get populated, and this
does work for now. But now that the m
From: Ville Syrjälä
Bunch of variables are only needed inside loops and whatnot.
Move them to a tighter scope to make the code less confusing.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_client_modeset.c | 33 +++-
1 file changed, 18 insertions(+), 15 deletions
From: Ville Syrjälä
The modes used by the client code live on the connectors' mode
lists, which are not owned by the client code, and thus it has
no business modifying the modes. Mark the modes const to make
that fact abundantly clear.
Reviewed-by: Jani Nikula
Reviewed-by: Thomas Zimmermann
Si
From: Ville Syrjälä
Get rid of all the redundant debugs and just wait until the end
to print which mode (and of which type) we picked.
Reviewed-by: Thomas Zimmermann
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_client_modeset.c | 70 +---
1 file changed, 33 ins
On Thu, Feb 27, 2025 at 11:38:05AM +0200, Jani Nikula wrote:
> Update GVT-g MAINTAINERS entry to reflect the current status of
> maintenance and repositories.
>
> Cc: Dave Airlie
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: Simona Vetter
> Cc: Tvrtko Ursulin
> Cc: Zhenyu Wang
> Cc: Zhi Wan
== Series Details ==
Series: drm/i915/vdsc: Use the DSC config tables for DSI panels (rev5)
URL : https://patchwork.freedesktop.org/series/145561/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_16205 -> Patchwork_145561v5
Su
On Fri, Feb 28, 2025 at 07:25:00PM +0200, Ville Syrjälä wrote:
> On Wed, Feb 26, 2025 at 07:35:04PM +0200, Imre Deak wrote:
> > [...]
> > static void i915_digport_work_func(struct work_struct *work)
> > {
> > - struct drm_i915_private *dev_priv =
> > - container_of(work, struct drm_i9
== Series Details ==
Series: drm/i915/vdsc: Use the DSC config tables for DSI panels (rev5)
URL : https://patchwork.freedesktop.org/series/145561/
State : warning
== Summary ==
Error: dim checkpatch failed
a0f49a32fec2 drm/i915/vdsc: Use the DSC config tables for DSI panels
-:26: WARNING:BAD_S
== Series Details ==
Series: series starting with [1/2] drm/xe/compat: refactor compat i915_drv.h
URL : https://patchwork.freedesktop.org/series/145648/
State : warning
== Summary ==
Error: dim checkpatch failed
de2667e05f1f drm/xe/compat: refactor compat i915_drv.h
-:37: WARNING:FILE_PATH_CHA
Hi Jani,
kernel test robot noticed the following build warnings:
[auto build test WARNING on next-20250228]
[also build test WARNING on linus/master v6.14-rc4]
[cannot apply to drm-xe/drm-xe-next v6.14-rc4 v6.14-rc3 v6.14-rc2]
[If your patch is applied to the wrong git tree, kindly drop us a
On Mon, Feb 24, 2025 at 06:00:49PM +0200, Jani Nikula wrote:
> In the interest of limiting the display dependencies on i915 core
> headers, split out i915_gtt_view_types.h from i915_vma_types.h, and only
> include the new header from intel_display_types.h.
>
> Reuse the new header from xe compat c
One opinion - consider it a nit, but maybe since all of the content of this new
header display specific, maybe instead of "i915_ggtt_view_types", why not
"i915_plane_gtt_types"
(or i915_display_gtt_types), if u plan to also expand to things across
plane<->pipe
...alan
On Mon, 2025-02-24 at 18:
On Wed, Feb 26, 2025 at 07:35:04PM +0200, Imre Deak wrote:
> Add support for blocking the IRQ handling on the HPD pin of a given
> encoder, handling IRQs that arrived while in the blocked state after
> unblocking the IRQ handling. This will be used by a follow-up change,
> which blocks/unblocks the
On Thu, Feb 27, 2025 at 10:18:31AM +, Kandpal, Suraj wrote:
>
>
> > -Original Message-
> > From: Jani Nikula
> > Sent: Tuesday, February 25, 2025 9:00 PM
> > To: Kandpal, Suraj ;
> > intel...@lists.freedesktop.org;
> > intel-gfx@lists.freedesktop.org; Syrjala, Ville
> > Cc: Nautiya
On Mon, Feb 24, 2025 at 06:00:48PM +0200, Jani Nikula wrote:
> With the primary goal of removing #include "i915_vma.h" from
> intel_display_types.h, move intel_plane_ggtt_offset() to a proper
> function in intel_atomic_plane.c. This reveals tons of implicit
> dependencies all over the place that we
Quoting Gustavo Sousa (2025-02-27 18:09:11-03:00)
>Fix one issue[1] reported by the kernel test robot and also take this
>opportunity to improve POWER_DOMAIN_*() macros by making them explicitly
>return the expected enum type with patch #2.
>
>I decided to send this new version with patch #3 droppe
Le 20/02/2025 à 10:45, Simona Vetter a écrit :
On Thu, Feb 20, 2025 at 09:31:41AM +0100, Greg KH wrote:
On Fri, Jan 24, 2025 at 11:45:14PM -0700, Jim Cromie wrote:
This series fixes dynamic-debug's support for DRM debug-categories.
Classmaps-v1 evaded full review, and got committed in 2 chun
On Tue, Feb 25, 2025 at 11:39:05PM +0530, Chaitanya Kumar Borah wrote:
> >From PTL, LUT registers are made double buffered. With this change,
> we don't need to wait for vblank to program them. Start DSB1 for
> programming them without waiting for vblank.
>
> Signed-off-by: Chaitanya Kumar Borah
Quoting Patchwork (2025-02-28 07:09:40-03:00)
>== Series Details ==
>
>Series: Improve type-safety on POWER_DOMAIN_*() macros (rev4)
>URL : https://patchwork.freedesktop.org/series/144726/
>State : failure
>
>== Summary ==
>
>CI Bug Log - changes from CI_DRM_16198_full -> Patchwork_144726v4_full
On Fri, 28 Feb 2025, Jani Nikula wrote:
> Going forward, struct intel_display is the main display device data
> pointer. Convert intel_atomic_plane.[ch] to struct intel_display.
>
> Signed-off-by: Jani Nikula
> ---
> .../gpu/drm/i915/display/intel_atomic_plane.c | 79 +--
> 1 fil
On Fri, Feb 28, 2025 at 02:49:30PM +0200, Jani Nikula wrote:
> Move port and mst_port members of struct intel_connector under an mst
> sub-struct to group mst related things together.
>
> Rename the latter dp for clarity.
>
> Cc: Imre Deak
> Signed-off-by: Jani Nikula
Reviewed-by: Imre Deak
Quoting Gustavo Sousa (2025-02-28 11:08:35-03:00)
>Quoting Patchwork (2025-02-28 04:25:37-03:00)
>>== Series Details ==
>>
>>Series: drm/i915/audio: Extend Wa_14020863754 to Xe3_LPD (rev2)
>>URL : https://patchwork.freedesktop.org/series/145492/
>>State : failure
>>
>>== Summary ==
>>
>>CI Bug Lo
> -Original Message-
> From: Ville Syrjälä
> Sent: Friday, February 28, 2025 7:57 PM
> To: Kandpal, Suraj
> Cc: Jani Nikula ; intel...@lists.freedesktop.org;
> intel-gfx@lists.freedesktop.org; Syrjala, Ville ;
> Nautiyal, Ankit K ; Shankar, Uma
> ; Kahola, Mika
> Subject: Re: [PATCH 0
Some DSI panel vendors end up hardcoding PPS params because of which
it does not listen to the params sent from the source. We use the
default config tables for DSI panels when using DSC 1.1 rather than
calculate our own rc parameters.
--v2
-Use intel_crtc_has_type [Jani]
--v4
-Use a function to
On Tue, Feb 25, 2025 at 11:39:04PM +0530, Chaitanya Kumar Borah wrote:
> >From PTL, LUT registers are made double buffered. This helps us
> to program them in the active region without any concern of tearing.
> This particulary helps in case of displays with high refresh rates
> where vblank period
> -Original Message-
> From: Nikula, Jani
> Sent: Friday, February 28, 2025 6:20 PM
> To: intel-gfx@lists.freedesktop.org; intel...@lists.freedesktop.org
> Cc: Nikula, Jani ; Kandpal, Suraj
>
> Subject: [PATCH 3/3] drm/i915/hdcp: add hdcp sub-struct to struct
> intel_digital_port
>
>
On Fri, Feb 28, 2025 at 09:13:53AM -0300, André Almeida wrote:
> To notify userspace about which app (if any) made the device get in a
> wedge state, make use of drm_wedge_app_info parameter, filling it with
> the app PID and name.
>
> Signed-off-by: André Almeida
> ---
> drivers/gpu/drm/amd/amd
The compat i915_drv.h contains things that aren't there in the original
i915_drv.h. Split out gem/i915_gem_object.h and i915_scheduler_types.h,
moving the corresponding pieces out, including FORCEWAKE_ALL to
intel_uncore.h.
Technically I915_PRIORITY_DISPLAY should be in i915_priolist_types.h,
but
Going forward, struct intel_display is the main display device data
pointer. Convert intel_atomic_plane.[ch] to struct intel_display.
Signed-off-by: Jani Nikula
---
.../gpu/drm/i915/display/intel_atomic_plane.c | 79 +--
1 file changed, 39 insertions(+), 40 deletions(-)
diff --g
Cc: Lucas
On Fri, Feb 28, 2025 at 09:13:52AM -0300, André Almeida wrote:
> When a device get wedged, it might be caused by a guilty application.
> For userspace, knowing which app was the cause can be useful for some
> situations, like for implementing a policy, logs or for giving a chance
> for t
== Series Details ==
Series: drm/i915/display: add some sub-structs for clarity
URL : https://patchwork.freedesktop.org/series/145641/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_16202 -> Patchwork_145641v1
Summary
--
Quoting Patchwork (2025-02-28 04:25:37-03:00)
>== Series Details ==
>
>Series: drm/i915/audio: Extend Wa_14020863754 to Xe3_LPD (rev2)
>URL : https://patchwork.freedesktop.org/series/145492/
>State : failure
>
>== Summary ==
>
>CI Bug Log - changes from CI_DRM_16198_full -> Patchwork_145492v2_ful
== Series Details ==
Series: drm/i915/display: add some sub-structs for clarity
URL : https://patchwork.freedesktop.org/series/145641/
State : warning
== Summary ==
Error: dim checkpatch failed
c1708cdf9cd9 drm/i915/mst: add mst sub-struct to struct intel_dp
95c39d7c2118 drm/i915/mst: add mst
== Series Details ==
Series: drm/i915/display: add some sub-structs for clarity
URL : https://patchwork.freedesktop.org/series/145641/
State : warning
== Summary ==
Error: patch
https://patchwork.freedesktop.org/api/1.0/series/145641/revisions/1/mbox/ not
found
Hi,
On 2025-02-26 at 13:41:34 GMT, Krzysztof Niemiec wrote:
> I have two suggestions for a different fix:
>
> 1. Disable the test on systems with NUMA and/or if it's running in a
> kthread, on the premise that it doesn't make sense to run this
> specific test in a kthread. This is the easier optio
== Series Details ==
Series: drm/i915/pxp & drm/xe/pxp: Figure out pxp instance from the gem object
(rev2)
URL : https://patchwork.freedesktop.org/series/144322/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_16202 -> Patchwork_144322v2
== Series Details ==
Series: drm: Create an app info option for wedge events
URL : https://patchwork.freedesktop.org/series/145638/
State : failure
== Summary ==
Error: patch
https://patchwork.freedesktop.org/api/1.0/series/145638/revisions/1/mbox/ not
applied
Applying: drm: Create an app in
Move port and mst_port members of struct intel_connector under an mst
sub-struct to group mst related things together.
Rename the latter dp for clarity.
Cc: Imre Deak
Signed-off-by: Jani Nikula
---
.../gpu/drm/i915/display/intel_connector.c| 4 +-
.../drm/i915/display/intel_display_debugf
Move hdcp_mutex, num_hdcp_streams, hdcp_auth_status, hdcp_port_data, and
hdcp_mst_type1_capable members of struct intel_digital_port under an
hdcp sub-struct to group hdcp related things together.
Rename them mutex, num_streams, auth_status, port_data, and
mst_type1_capable for clarity.
Cc: Suraj
Move active_mst_links, mst_encoders[], and mst_mgr members of struct
intel_dp under an mst sub-struct to group mst related things together.
Rename them active_links, stream_encoders[] and mgr for clarity.
Note that is_mst and mst_detect are not included, as they're also
relevant for non-mst. The
Jani Nikula (3):
drm/i915/mst: add mst sub-struct to struct intel_dp
drm/i915/mst: add mst sub-struct to struct intel_connector
drm/i915/hdcp: add hdcp sub-struct to struct intel_digital_port
drivers/gpu/drm/i915/display/g4x_dp.c | 2 +-
drivers/gpu/drm/i915/display/g4x_hdmi.c
== Series Details ==
Series: drm/i915/fbc: FBC Dirty rect feature support (rev4)
URL : https://patchwork.freedesktop.org/series/144725/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_16202 -> Patchwork_144725v4
Summary
-
On 2/28/2025 2:35 AM, Ville Syrjälä wrote:
On Thu, Feb 27, 2025 at 04:31:28PM +0530, Nautiyal, Ankit K wrote:
On 2/26/2025 8:41 PM, Ville Syrjälä wrote:
On Mon, Feb 24, 2025 at 11:47:15AM +0530, Ankit Nautiyal wrote:
For fixed refresh rate use fixed timings for all platforms that support
VRR
To notify userspace about which app (if any) made the device get in a
wedge state, make use of drm_wedge_app_info parameter, filling it with
the app PID and name.
Signed-off-by: André Almeida
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 19 +--
drivers/gpu/drm/amd/amdgpu/amdg
== Series Details ==
Series: drm/i915/fbc: FBC Dirty rect feature support (rev4)
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 (rev4)
URL : https://patchwork.freedesktop.org/series/144725/
State : warning
== Summary ==
Error: dim checkpatch failed
84e05b0b9719 drm/i915/fbc: remove one duplicate forward declaration
6dc025b87e01 drm/damage-helper:
When a device get wedged, it might be caused by a guilty application.
For userspace, knowing which app was the cause can be useful for some
situations, like for implementing a policy, logs or for giving a chance
for the compositor to let the user know what app caused the problem.
This is an optiona
This patchset implements a request made by Xaver Hugl about wedge events:
"I'd really like to have the PID of the client that triggered the GPU
reset, so that we can kill it if multiple resets are triggered in a
row (or switch to software rendering if it's KWin itself) and show a
user-friendly not
It's undesirable to have to figure out the pxp pointer in display
code. For one thing, its type is different for i915 and xe.
Since we can figure the pxp pointer out in the pxp code from the gem
object, offload it there.
v2: Rebase
Cc: Daniele Ceraolo Spurio
Cc: Alan Previn
Reviewed-by: Daniel
> -Original Message-
> From: Yu, Gareth
> Sent: Friday, February 28, 2025 6:46 AM
> To: Kandpal, Suraj
> Cc: Nautiyal, Ankit K ; intel-
> g...@lists.freedesktop.org; intel...@lists.freedesktop.org; Nikula, Jani
> ; Shankar, Uma ; Tseng,
> William
> Subject: Re: [PATCH] drm/i915/vdsc:
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
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
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
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.
Reviewed-by: Ville Syrjälä
Signed-of
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
On Friday, 28 February 2025 08:49:21 CET Mikolaj Wasiak wrote:
> Hi Janusz,
>
> > I agree with both Andi and Krzysztof comments.
> >
> > If the issue is tracked in our bug tracker then please provide a link to
> > its
> > record in a Link: or even Closes: tag. Do you have call traces on hand?
Hi,
On Thu, 27 Feb 2025, Gustavo Sousa wrote:
> In Xe3_LPD, display audio has the core audio logic located in PG0 and
> per-transcoder logic in the same power well that provides power for the
> transcoder [1].
[...]
> Since intel_audio_component_get_power() uses
> POWER_DOMAIN_AUDIO_PLAYBACK, mak
Remove the duplicate "intel_display"declaration from intel_fbc.h
Signed-off-by: Vinod Govindapillai
---
drivers/gpu/drm/i915/display/intel_fbc.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.h
b/drivers/gpu/drm/i915/display/intel_fbc.h
index df20e63d6
During enabling FBC, for the very first frame, the prepare dirty
rect routine wouldnt have executed as at that time the plane
reference in the fbc_state would be NULL. So this could make
driver program some invalid entries as the damage area. Though
fbc hw ignores the dirty rect values programmed f
On Fri, 28 Feb 2025, Vinod Govindapillai wrote:
> Remove the duplicate "intel_display"declaration from intel_fbc.h
>
> Signed-off-by: Vinod Govindapillai
Mea culpa,
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_fbc.h | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git
Introduce a macro to check if the platform supports FBC dirty
rect capability.
v2: - update to the patch subject
Reviewed-by: Ville Syrjälä
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
Register definitions for FBC dirty rect support
v2: - update to the patch subject
Bspec: 71675, 73424
Reviewed-by: Ville Syrjälä
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/i91
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 Fri, 28 Feb 2025, Suraj Kandpal wrote:
> Some DSI panel vendors end up hardcoding PPS params because of which
> it does not listen to the params sent from the source. We use the
> default config tables for DSI panels when using DSC 1.1 rather than
> calculate our own rc parameters.
>
> --v2
> -
Hi Janusz,
> I agree with both Andi and Krzysztof comments.
>
> If the issue is tracked in our bug tracker then please provide a link to its
> record in a Link: or even Closes: tag. Do you have call traces on hand?
> Probably yes, so please consider adding a concise excerpt to your descriptio
Hi Maarten
Am 12.02.25 um 08:28 schrieb Maarten Lankhorst:
Hey,
I'll give it a spin on xe today. It seems someone already tried on i915,
so I expect no issues.
Did you get to test the series?
Best regards
Thomas
The only question I have is do we still inherit the BIOS fb on boot
for fbdev
77 matches
Mail list logo
