> -Original Message-
> From: Kandpal, Suraj
> Sent: Friday, February 21, 2025 11:43 AM
> To: Tseng, William ; intel-gfx@lists.freedesktop.org
> Cc: Heikkila, Juha-pekka
> Subject: RE: [PATCH v2] drm/i915/dsc: Change rc parameters calculation for
> DSC 1.1
>
>
>
> > -Original Mes
> -Original Message-
> From: Yu, Gareth
> Sent: Friday, February 21, 2025 10:35 AM
> To: Kandpal, Suraj ; intel-gfx@lists.freedesktop.org
> Cc: intel...@lists.freedesktop.org; Tseng, William ;
> Nautiyal, Ankit K ; Heikkila, Juha-pekka pekka.heikk...@intel.com>
> Subject: RE: [PATCH] d
From: Gareth Yu
The condition change is because Gen 14 begins to support DSC 1.2
and need to check if the sink supports DSC1.2
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13719
Cc: Suraj Kandpal
Cc: Juha-Pekka Heikkil
Signed-off-by: Gareth Yu
---
drivers/gpu/drm/i915/dis
> -Original Message-
> From: Yu, Gareth
> Sent: Friday, February 21, 2025 10:35 AM
> To: Kandpal, Suraj ; intel-gfx@lists.freedesktop.org
> Cc: intel...@lists.freedesktop.org; Tseng, William ;
> Nautiyal, Ankit K ; Heikkila, Juha-pekka pekka.heikk...@intel.com>
> Subject: RE: [PATCH] d
== Series Details ==
Series: drm/i915/vdsc: Correct the conditions of DSC1.1 and DSC 1.2 for rc
params calculation
URL : https://patchwork.freedesktop.org/series/145209/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_16166 -> Patchwork_145209v1
> -Original Message-
> From: Kandpal, Suraj
> Sent: Friday, February 21, 2025 12:44 PM
> To: Yu, Gareth ; intel-gfx@lists.freedesktop.org
> Cc: intel...@lists.freedesktop.org; Tseng, William ;
> Nautiyal, Ankit K ; Heikkila, Juha-pekka pekka.heikk...@intel.com>
> Subject: RE: [PATCH] d
== Series Details ==
Series: drm/i915/vdsc: Correct the conditions of DSC1.1 and DSC 1.2 for rc
params calculation
URL : https://patchwork.freedesktop.org/series/145209/
State : warning
== Summary ==
Error: dim checkpatch failed
1e9add002d68 drm/i915/vdsc: Correct the conditions of DSC1.1 and
> -Original Message-
> From: Yu, Gareth
> Sent: Friday, February 21, 2025 9:44 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: intel...@lists.freedesktop.org; shawn.c.lee.intel.om; Tseng, William
> ; Nautiyal, Ankit K ; Yu,
> Gareth ; Kandpal, Suraj ;
> Heikkila, Juha-pekka
> Subject: [
Hi Matt,
kernel test robot noticed the following build warnings:
[auto build test WARNING on next-20250220]
[cannot apply to drm-xe/drm-xe-next v6.14-rc3 v6.14-rc2 v6.14-rc1 linus/master
v6.14-rc3]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch
> -Original Message-
> From: Tseng, William
> Sent: Friday, February 21, 2025 7:27 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Tseng, William ; Kandpal, Suraj
> ; Heikkila, Juha-pekka pekka.heikk...@intel.com>
> Subject: [PATCH v2] drm/i915/dsc: Change rc parameters calculation for
== Series Details ==
Series: Stop accessing display TIMESTAMP_OVERRIDE in GT code
URL : https://patchwork.freedesktop.org/series/145201/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_16166 -> Patchwork_145201v1
Summary
On Thu, Feb 20, 2025 at 04:38:47PM -0800, Matt Roper wrote:
On pre-Xe2 platforms, one of the approaches to initialize the GT command
streamer frequency is to use the display reference clock. That's no
longer relevant from Xe2 onward (i.e., all of the platforms where Xe is
officially supported).
== Series Details ==
Series: drm/i915/dsc: Change rc parameters calculation for DSC 1.1 (rev2)
URL : https://patchwork.freedesktop.org/series/145136/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_16166 -> Patchwork_145136v2
== Series Details ==
Series: drm/i915/dsb: Update plane scalers on DSB (rev2)
URL : https://patchwork.freedesktop.org/series/145043/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_16166 -> Patchwork_145043v2
Summary
---
== Series Details ==
Series: drm/i915/dsb: Update plane scalers on DSB (rev2)
URL : https://patchwork.freedesktop.org/series/145043/
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/bi
== Series Details ==
Series: Stop accessing display TIMESTAMP_OVERRIDE in GT code
URL : https://patchwork.freedesktop.org/series/145201/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
When calculating dsc parameters, the rc parameters calculated by
calculate_rc_params() is incorrect in the case of DSC 1.1 and
DISPLAY_VER(dev_priv) >= 13. It turns out to be some noise-like
lines are displayed on a MIPI DSI panel supporting DSC 1.1.
The function calculate_rc_params() is implement
TIMESTAMP_OVERRIDE is never used to initialize the GT clock frequency on
Xe2 platforms (and the register itself no longer exists on LNL) so drop
it from the list of runtime registers.
Cc: Michal Wajdeczko
Cc: Jakub Kolakowski
Acked-by: Michal Wajdeczko
Reviewed-by: Lucas De Marchi
Signed-off-b
The whole GT CS clock initialization area is poorly documented in the
specs and a lot of this code seems to have been inherited from the
Windows driver team long ago. There's nothing in the specs that
specifically explains using the display reference frequency, as taken
from TIMESTAMP_OVERRIDE reg
There's cdclk-specific code to obtain the display reference clock,
either by reading a strap register, or by using a platform-specific
hardcoded value. There's at least one other place in our drivers that
potentially needs this clock frequency, so refactor the logic to make it
more generally usabl
On pre-Xe2 platforms, one of the approaches to initialize the GT command
streamer frequency is to use the display reference clock. That's no
longer relevant from Xe2 onward (i.e., all of the platforms where Xe is
officially supported). Furthermore, use of TIMESTAMP_OVERRIDE to obtain
the display
When determining the GT command streamer frequency, there are two
approaches used by i915 and Xe:
- Derive the CS frequency from the crystal clock frequency register (or
a per-platform hardcoded value). This is supposed to be the method
usually used (and the only method supported at all fo
The ticket, https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13719, was
created for this. You can use it or create a new one.
> > -Original Message-
> > From: Kandpal, Suraj
> > Sent: Thursday, February 20, 2025 2:01 PM
> > To: Tseng, William ;
> > intel-gfx@lists.freedesktop.or
On 2/20/25 10:27, Lucas De Marchi wrote:
> On Thu, Feb 20, 2025 at 08:28:01AM -0800, Dave Hansen wrote:
>> On 2/20/25 07:36, Lucas De Marchi wrote:
>>> On some boots the read of MSR_PP1_ENERGY_STATUS msr returns 0, causing
>>> perf_msr_probe() to make the power/events/energy-gpu event non-visible.
Hi Sebastian,
On Thursday, 20 February 2025 17:10:57 CET Sebastian Brzezinka wrote:
> Hi Janusz
>
> On Wed Feb 19, 2025 at 6:37 PM UTC, Janusz Krzysztofik wrote:
> > Starting with commit ec3e00b4ee27 ("drm/i915: stop registering if
> > drm_dev_register() fails"), we return immediately from
> > i9
On Thu, Feb 20, 2025 at 11:47:21AM -0500, Liang, Kan wrote:
On 2025-02-20 10:36 a.m., Lucas De Marchi wrote:
On some boots the read of MSR_PP1_ENERGY_STATUS msr returns 0, causing
perf_msr_probe() to make the power/events/energy-gpu event non-visible.
When that happens, the msr always read 0 u
On Thu, Feb 20, 2025 at 08:28:01AM -0800, Dave Hansen wrote:
On 2/20/25 07:36, Lucas De Marchi wrote:
On some boots the read of MSR_PP1_ENERGY_STATUS msr returns 0, causing
perf_msr_probe() to make the power/events/energy-gpu event non-visible.
When that happens, the msr always read 0 until the
Hey,
On 2025-02-20 16:43, Matthew Auld wrote:
On 20/02/2025 14:22, Lucas De Marchi wrote:
On Wed, Feb 19, 2025 at 04:34:40PM +0100, Maarten Lankhorst wrote:
The fbdev vma is a normal unrotated VMA, so add ane explicit check
before re-using.
When re-using, we have to restore the GGTT mapping o
Hi Dave and Sima,
Here goes our i915 fixes for this round. Mostly display related,
with the exception of the spin_lock_irqsave conversion on guc submission.
Thanks,
Rodrigo.
drm-intel-fixes-2025-02-20:
- Use spin_lock_irqsave() in interruptible context on guc submission (Krzysztof)
- Fixes on DD
On 2025-02-20 10:36 a.m., Lucas De Marchi wrote:
> On some boots the read of MSR_PP1_ENERGY_STATUS msr returns 0, causing
> perf_msr_probe() to make the power/events/energy-gpu event non-visible.
> When that happens, the msr always read 0 until the graphics module (i915
> for Meteor Lake, xe for
Hi Dave and Sima,
Here goes our round of Xe fixes of this week.
Thanks,
Rodrigo.
drm-xe-fixes-2025-02-20:
- Fix error handling in xe_irq_install (Lucas)
- Fix devcoredump format (Jose, Lucas)
The following changes since commit 0ad2507d5d93f39619fc42372c347d6006b64319:
Linux 6.14-rc3 (2025-02
== Series Details ==
Series: perf/x86/rapl: Fix PP1 event for Intel Meteor/Lunar Lake
URL : https://patchwork.freedesktop.org/series/145184/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_16164 -> Patchwork_145184v1
Summary
== Series Details ==
Series: perf/x86/rapl: Fix PP1 event for Intel Meteor/Lunar Lake
URL : https://patchwork.freedesktop.org/series/145184/
State : warning
== Summary ==
Error: dim checkpatch failed
52a64a338612 perf/x86/rapl: Fix PP1 event for Intel Meteor/Lunar Lake
-:32: ERROR:BAD_SIGN_OFF
On 2/20/25 07:36, Lucas De Marchi wrote:
> On some boots the read of MSR_PP1_ENERGY_STATUS msr returns 0, causing
> perf_msr_probe() to make the power/events/energy-gpu event non-visible.
> When that happens, the msr always read 0 until the graphics module (i915
> for Meteor Lake, xe for Lunar Lake
On Tue, Feb 18, 2025 at 11:13:39AM +0530, Murthy, Arun R wrote:
> On 17-02-2025 15:38, Pekka Paalanen wrote:
> > Hi Arun,
> >
> > this whole series seems to be missing all the UAPI docs for the DRM
> > ReST files, e.g. drm-kms.rst. The UAPI header doc comments are not a
> > replacement for them, I
On some boots the read of MSR_PP1_ENERGY_STATUS msr returns 0, causing
perf_msr_probe() to make the power/events/energy-gpu event non-visible.
When that happens, the msr always read 0 until the graphics module (i915
for Meteor Lake, xe for Lunar Lake) is loaded. Then it starts returning
something d
Hi Janusz
On Wed Feb 19, 2025 at 6:37 PM UTC, Janusz Krzysztofik wrote:
> Starting with commit ec3e00b4ee27 ("drm/i915: stop registering if
> drm_dev_register() fails"), we return immediately from
> i915_driver_register() if drm_dev_register() fails, skipping remaining
> registration steps. Howev
On Wed, 19 Feb 2025 09:28:51 +0530
"Murthy, Arun R" wrote:
> On 18-02-2025 21:48, Pekka Paalanen wrote:
> > On Tue, 18 Feb 2025 11:13:39 +0530
> > "Murthy, Arun R" wrote:
> >
> >> On 17-02-2025 15:38, Pekka Paalanen wrote:
> >>> Hi Arun,
> >>>
> >>> this whole series seems to be missing all t
On 20/02/2025 14:22, Lucas De Marchi wrote:
On Wed, Feb 19, 2025 at 04:34:40PM +0100, Maarten Lankhorst wrote:
The fbdev vma is a normal unrotated VMA, so add ane explicit check
before re-using.
When re-using, we have to restore the GGTT mapping on resume, so add
some code to do that too.
Fixe
Hi,
On 2/20/2025 2:53 PM, Tvrtko Ursulin wrote:
>
> On 20/02/2025 13:14, Jacek Lawrynowicz wrote:
>> Hi,
>>
>> On 2/19/2025 11:55 AM, Joonas Lahtinen wrote:
>>> Quoting Jacek Lawrynowicz (2025-02-11 17:57:03)
Hi, can I submit this to drm-misc or should someone commit this to
drm-intel?
On Thu, Feb 20, 2025 at 11:00:28AM +0100, Simona Vetter wrote:
> 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
On Wed, Feb 19, 2025 at 04:34:40PM +0100, Maarten Lankhorst wrote:
The fbdev vma is a normal unrotated VMA, so add ane explicit check
before re-using.
When re-using, we have to restore the GGTT mapping on resume, so add
some code to do that too.
Fixes: 67a98f7e27ba ("drm/xe/display: Re-use disp
On 20/02/2025 13:14, Jacek Lawrynowicz wrote:
Hi,
On 2/19/2025 11:55 AM, Joonas Lahtinen wrote:
Quoting Jacek Lawrynowicz (2025-02-11 17:57:03)
Hi, can I submit this to drm-misc or should someone commit this to drm-intel?
Is the this happening in linux-next or is it still completely out-of
Hi,
On 2/19/2025 11:55 AM, Joonas Lahtinen wrote:
> Quoting Jacek Lawrynowicz (2025-02-11 17:57:03)
>> Hi, can I submit this to drm-misc or should someone commit this to drm-intel?
>
> Is the this happening in linux-next or is it still completely out-of-tree?
The patch is not merged so it is happ
== Series Details ==
Series: drm/i915/fbc: FBC Dirty rect feature support (rev3)
URL : https://patchwork.freedesktop.org/series/144725/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_16162 -> Patchwork_144725v3
Summary
-
> -Original Message-
> From: Kandpal, Suraj
> Sent: Thursday, February 20, 2025 2:01 PM
> To: Tseng, William ; intel-gfx@lists.freedesktop.org
> Cc: Heikkila, Juha-pekka ; Nautiyal, Ankit K
>
> Subject: RE: [PATCH] drm/i915/dsc: Change rc parameters calculation for DSC
> 1.1
>
>
>
>
== Series Details ==
Series: drm/i915/fbc: FBC Dirty rect feature support (rev3)
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 (rev3)
URL : https://patchwork.freedesktop.org/series/144725/
State : warning
== Summary ==
Error: dim checkpatch failed
d7c5bfbf3776 drm/damage-helper: add const qualifier in
drm_atomic_helper_damage_merged()
f33f14d1b
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
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
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
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
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
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
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
== Series Details ==
Series: drm/i915/selftests: Re-enable power gating after live_selftest (rev2)
URL : https://patchwork.freedesktop.org/series/145144/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_16162 -> Patchwork_145144v2
=
On Fri, 2025-02-07 at 23:54 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Make intel_crtc_scanline_offset() a bit less confusing by
> fully reordering the if ladder to use the new->old platform
> order.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jouni Högander
> ---
> drivers/gpu
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
> >
On Fri, 2025-02-07 at 23:54 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The HDMI vs. not scanline offset stuff no longer applies to the
> latest platforms, so using HAS_DDI() is a bit confusing. Replace
> with a more specific set of conditions.
>
> Also let's just deal with the platfor
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
> plumbs these straight through into the kernel as DPMS setproperty
> ioctls,
From: Sk Anirban
The current implementation of live_rc6_manual disables power gating
after execution due to the deactivation of RC6.
This update aims to re-enable power gating following the completion
of the self-test. However, as a temporary workaround
for forcewake timeouts, power gating will r
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 chunks:
> >
> > b7b4eebdba7b..6ea3bf466ac6
On Fri, 2025-02-07 at 23:54 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Turns out LNL+ and BMG+ no longer have the weird extra scanline
> offset for HDMI outputs. Fix intel_crtc_scanline_offset()
> accordingly so that scanline evasion/etc. works correctly on
> HDMI outputs on these new
Hi Dave, Sima,
this is the weekly PR for drm-misc-next. It has quite a number of
highlights:
* There is the new device wedge event, which allows drivers to report
unresponsive hardware to user space via a uevent. Drivers for AMD and
Intel HW already use the functionality.
* The i2c subdirect
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 chunks:
>
> b7b4eebdba7b..6ea3bf466ac6 # core dyndbg changes
> 0406faf25fb1..ee7d633f2dfb # drm adoption
Hi,
Here's this week drm-misc-fixes PR
Maxime
drm-misc-fixes-2025-02-20:
An reset signal polarity fix for the jd9365da-h3 panel, a folio handling
fix and config fix in nouveau, a dmem cgroup descendant pool handling
fix, and a missing header for amdxdna.
The following changes since commit e00a2e
patch link:
https://lore.kernel.org/r/20250219115359.2320992-2-nemesa.garg%40intel.com
patch subject: [PATCH 1/6] drm: Introduce sharpness strength property
config: s390-allyesconfig
(https://download.01.org/0day-ci/archive/20250220/202502201640.kv91rrh2-...@intel.com/config)
compiler: s390
69 matches
Mail list logo
