== Series Details ==
Series: drm/i915: Precompute plane SURF address/etc.
URL : https://patchwork.freedesktop.org/series/147097/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_16361 -> Patchwork_147097v1
Summary
---
*
On 01/04/2025 19:47, Ville Syrjälä wrote:
On Tue, Apr 01, 2025 at 02:51:10PM +0200, Jocelyn Falempe wrote:
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
---
v5:
* Use io
== Series Details ==
Series: drm/i915: Precompute plane SURF address/etc.
URL : https://patchwork.freedesktop.org/series/147097/
State : warning
== Summary ==
Error: patch
https://patchwork.freedesktop.org/api/1.0/series/147097/revisions/1/mbox/ not
found
Add a basic test that uses PMU to read GT actual and requested
frequencies while running a workload.
Cc: Lucas De Marchi
Cc: Rodrigo Vivi
Signed-off-by: Vinay Belgaumkar
---
tests/intel/xe_pmu.c | 93
1 file changed, 93 insertions(+)
diff --git a/t
Also move some frequency helpers to lib.
Signed-off-by: Vinay Belgaumkar
Vinay Belgaumkar (2):
lib/xe_gt: Move get/set GT freq utils to lib
tests/xe_pmu: Add frequency test
lib/xe/xe_gt.c | 59 ++
lib/xe/xe_gt.h | 2 +
tests/intel/xe_gt_freq.c | 164 +
These can be used from other tests as well.
Signed-off-by: Vinay Belgaumkar
---
lib/xe/xe_gt.c | 59 ++
lib/xe/xe_gt.h | 2 +
tests/intel/xe_gt_freq.c | 164 +++
3 files changed, 125 insertions(+), 100 deletions(-)
diff --gi
From: Ville Syrjälä
dpt_total_entries() is not used anywhere. Remove it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dpt.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c
b/drivers/gpu/drm/i915/display/intel_dpt.c
index 2bf
From: Ville Syrjälä
Include a precomputed plane SURF address in the plane state,
so that all the vma stuff is contained in the *_fb_pin.c code.
Additionally we can also now easily include the SURF address in
some of the plane tracepoints to aid in eg. analyzing faults.
Ville Syrjälä (9):
drm/i
From: Ville Syrjälä
When analying plane faults the exact sequence/timing of things can be
important. Add a tracepoint for plane faults that can then be
correclated against other tracepoints to figure out what happened and
when.
Signed-off-by: Ville Syrjälä
---
.../gpu/drm/i915/display/intel_di
From: Ville Syrjälä
The plane fault tracepoints report the plane control and
surface register values. In order to correlate those against the
plane update tracepoints it might be helpful to also include that
information in the plane update tracepoints as well.
The one caveat here is that the pre
From: Ville Syrjälä
Now that we handle all the other vma offset stuff in
intel_plane_pin_fb() it seems more proper to do the
dpt_vma offset check there as well.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fb_pin.c| 7 +++
drivers/gpu/drm/i915/display/skl_uni
From: Ville Syrjälä
The *_plane_ctl() functions only consider the state of the
plane (the state of the crtc is handled by the corresponding
*_plane_ctl_crtc()), and thus they don't need the crtc_state
at all. Don't pass it in.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/i9xx_
From: Ville Syrjälä
Currently we pre-compute the plane surface/base address
partially (only for cursor_needs_physical cases) in
intel_plane_pin_fb() and finish the calculation in the
plane->update_arm(). Let's just precompute the whole thing
instead.
One benefit is that we get rid of all the vma
From: Ville Syrjälä
Replace the open coded vma mm node stuff in intel_dpt_offset()
with i915_vma_offset(). This will also include the VT-d guard
in the result. Granted that should always be 0 for DPT, but
it seems prudent to include that in our DPT vma offset check
anyway.
Signed-off-by: Ville S
Hi Ville,
> > if (i915_gem_context_is_recoverable(eb->gem_context) &&
> > - (IS_DGFX(eb->i915) || GRAPHICS_VER_FULL(eb->i915) >
> > IP_VER(12, 0)))
> > + GRAPHICS_VER_FULL(eb->i915) > IP_VER(12, 10))
>
> How is this is more relaxed than the old version?
n
On 01/04/2025 19:57, Ville Syrjälä wrote:
On Tue, Apr 01, 2025 at 08:47:50PM +0300, Ville Syrjälä wrote:
On Tue, Apr 01, 2025 at 02:51:10PM +0200, Jocelyn Falempe wrote:
Prepare the work for drm_panic support. This is used to map the
current framebuffer, so the CPU can overwrite it with the pan
From: Ville Syrjälä
Dunno why we still have .require_force_probe=1 on DG1 after
all this time. I'm not aware of any real problems with DG1,
so get rid of the force_probe requirement.
Generally the difficulty with DG1 is that it requires a
4GiB BAR for the local memory, and that's not something
t
== Series Details ==
Series: drm/i915/display: Add link rate and lane count to i915_display_info
(rev2)
URL : https://patchwork.freedesktop.org/series/146468/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_16360 -> Patchwork_146468v2
===
On 01/04/2025 19:38, Ville Syrjälä wrote:
On Tue, Apr 01, 2025 at 02:51:08PM +0200, Jocelyn Falempe wrote:
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
* Dr. David Alan Gilbert wrote:
> * Ingo Molnar (mi...@kernel.org) wrote:
> >
> > * li...@treblig.org wrote:
> >
> > > From: "Dr. David Alan Gilbert"
> > >
> > > The last use of iosf_mbi_unregister_pmic_bus_access_notifier() was
> > > removed in 2017 by
> > > commit a5266db4d314 ("drm/i915
== Series Details ==
Series: drm/i915: DG1 fixes
URL : https://patchwork.freedesktop.org/series/147081/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_16358 -> Patchwork_147081v1
Summary
---
**SUCCESS**
No regressi
== Series Details ==
Series: drm/i915: DG1 fixes
URL : https://patchwork.freedesktop.org/series/147081/
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/bitops.h:116:1: warning: unrepl
On Tue, Apr 01, 2025 at 08:47:50PM +0300, Ville Syrjälä wrote:
> On Tue, Apr 01, 2025 at 02:51:10PM +0200, Jocelyn Falempe wrote:
> > 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-
On Tue, Apr 01, 2025 at 07:34:11PM +0200, Andi Shyti wrote:
> Hi Ville,
>
> On Tue, Apr 01, 2025 at 07:37:51PM +0300, Ville Syrjala wrote:
> > The intel-media-driver is currently broken on DG1 because
> > it uses EXEC_CAPTURE with recovarable contexts. Relax the
> > check to allow that.
> >
> > I
On Tue, Apr 1, 2025 at 9:19 PM Jani Nikula wrote:
>
> The header tests track whether headers have been checked using empty
> *.hdrtest files in the build tree. This pollutes the build directories,
> as the files live in the same "name space" as the real output files,
> messing with TAB completion
On Tue, Apr 01, 2025 at 02:51:10PM +0200, Jocelyn Falempe wrote:
> 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
> ---
>
> v5:
> * Use iosys_map for intel_bo_panic_m
On Tue, Apr 01, 2025 at 02:51:08PM +0200, Jocelyn Falempe wrote:
> 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/displ
Hi Ville,
On Tue, Apr 01, 2025 at 07:37:52PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Dunno why we still have .require_force_probe=1 on DG1 after
> all this time. I'm not aware of any real problems with DG1,
> so get rid of the force_probe requirement.
Excellent!
> Generally the d
Hi Ville,
On Tue, Apr 01, 2025 at 07:37:51PM +0300, Ville Syrjala wrote:
> The intel-media-driver is currently broken on DG1 because
> it uses EXEC_CAPTURE with recovarable contexts. Relax the
> check to allow that.
>
> I've also submitted a fix for the intel-media-driver:
> https://github.com/in
On Tue, Apr 01, 2025 at 01:27:14PM +, Kumar, Naveen1 wrote:
> Hi Ville,
>
> >-Original Message-
> >From: Ville Syrjälä
> >Sent: Monday, March 31, 2025 9:28 PM
> >To: Murthy, Arun R
> >Cc: dri-de...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; intel-
> >x...@lists.freedeskt
From: Ville Syrjälä
We are applying the combo PLL frac w/a to all TGL+ platforms, except
RKL. I *think* all RKL machines use a 24 MHz refclk (certainly all
machines in our CI do) and so technically never need the adjustment.
But let's assume the hardware is exactly the same anyway and simplify
th
From: Ville Syrjälä
The intel-media-driver is currently broken on DG1 because
it uses EXEC_CAPTURE with recovarable contexts. Relax the
check to allow that.
I've also submitted a fix for the intel-media-driver:
https://github.com/intel/media-driver/pull/1920
Cc: sta...@vger.kernel.org
Cc: Matth
From: Ville Syrjälä
DG1 apparently needs the combo PLL fractional divider w/a
with 38.4 MHz refclk as well. This isn't listed in bspec, but
looking at the hsd it looks like it was possibly just missed
due to no one having a DG1 around at the time.
This gives us slightly more accurate clocks on D
From: Ville Syrjälä
Fix a couple of problems on DG1, and remove the long overdue
force_probe requirement.
Ville Syrjälä (4):
drm/i915: Apply the combo PLL frac w/a on DG1
drm/i915: Simplify combo PLL frac w/a
drm/i915/gem: Allow EXEC_CAPTURE on recoverable contexts on DG1
drm/i915/pci: R
On Tue, Mar 18, 2025 at 09:10:38AM +0100, Thomas Hellström wrote:
> On Mon, 2025-03-17 at 22:30 +, Matthew Wilcox wrote:
> > This patch fixes the compilation problem. But I don't understand why
> > it's messing with the reclaim flag. Thomas, can you explain?
>
> Hi, Sorry for not responding
Hello Alexander,
On 26/03/2025 at 17:26:12 +02, Alexander Usyskin
wrote:
> Create master device without partition when
> CONFIG_MTD_PARTITIONED_MASTER flag is unset.
>
> This streamlines device tree and allows to anchor
> runtime power management on master device in all cases.
>
> Signed-off-by
On Tue, 01 Apr 2025, Imre Deak wrote:
> The return value on success of drm_dp_send_dpcd_write() called for
> non-root MST branch devices from drm_dp_check_mstb_guid() is the number
> of bytes transferred. Atm this return value (in case of a complete read)
> will be regarded incorrectly as an error
Hi Andi,
On 2025-03-29 at 08:18:33 +0100, Andi Shyti wrote:
> On Fri, Mar 21, 2025 at 03:02:49PM +0100, Mikolaj Wasiak wrote:
> > Due to changes in allocator, the size of the allocation for
>
> which change in the allocator?
[8569c31545385195bdb0c021124e68336e91c693] drm/i915:
Move the size comp
On Alder Lake 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 i
On Tue, 01 Apr 2025, Jocelyn Falempe wrote:
> This adds drm_panic support for a wide range of Intel GPU. I've
> tested it only on 4 laptops, Haswell (with 128MB of eDRAM),
> Comet Lake, Raptor Lake, and Lunar Lake.
> For hardware using DPT, it's not possible to disable tiling, as you
> will need t
On 27.03.25 18:22, Zi Yan wrote:
On Thu Mar 27, 2025 at 12:52 PM EDT, Matthew Wilcox wrote:
On Thu, Mar 27, 2025 at 11:04:57AM -0400, Zi Yan wrote:
On Fri Mar 7, 2025 at 8:54 AM EST, Matthew Wilcox (Oracle) wrote:
The writepage callback is going away; filesystems must implement
migrate_folio o
Hi Ville,
>-Original Message-
>From: Ville Syrjälä
>Sent: Monday, March 31, 2025 9:28 PM
>To: Murthy, Arun R
>Cc: dri-de...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; intel-
>x...@lists.freedesktop.org; Jani Nikula ; Borah,
>Chaitanya Kumar ; Syrjala, Ville
>; Kumar, Naveen1
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
The return value on success of drm_dp_send_dpcd_write() called for
non-root MST branch devices from drm_dp_check_mstb_guid() is the number
of bytes transferred. Atm this return value (in case of a complete read)
will be regarded incorrectly as an error by the caller of
drm_dp_check_mstb_guid(). Fix
On Alder Lake 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 | 69 ++-
.../drm/i915/display
== Series Details ==
Series: hdrtest: hide the disgusting turds
URL : https://patchwork.freedesktop.org/series/147058/
State : failure
== Summary ==
Error: patch
https://patchwork.freedesktop.org/api/1.0/series/147058/revisions/1/mbox/ not
applied
Applying: drm: place header test files in .h
This adds drm_panic support for a wide range of Intel GPU. I've
tested it only on 4 laptops, Haswell (with 128MB of eDRAM),
Comet Lake, Raptor 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
framebuf
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
---
v5:
* Use iosys_map for intel_bo_panic_map().
drivers/gpu/drm/i915/display/intel_bo.c| 5
drivers/gpu/drm/i915/
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 i7-10850H
* Raptor Lake i7-1370P (with DPT, and Y-tiling).
* Lunar Lake Ultra 5 228V (with DPT, and 4-tiling, and using the Xe driver.
I tes
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(+)
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
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 int
The DRM subsystem contains additional build-time checks, primarily aimed
at DRM developers and CI systems. The checks may be overzealous. They
may slow down or fail the build altogether. They may create excessive
dependency files in the build tree. They should not be enabled for
regular builds, and
== Series Details ==
Series: series starting with [1/2] drm/dp_mst: Fix GUID DPCD write to non-root
MST branch devices
URL : https://patchwork.freedesktop.org/series/147054/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_16355 -> Patchwork_147054v1
The header tests track whether headers have been checked using empty
*.hdrtest files in the build tree. This pollutes the build directories,
as the files live in the same "name space" as the real output files,
messing with TAB completion among other things.
Hide the disgusting turds by placing the
The header tests track whether headers have been checked using empty
*.hdrtest files in the build tree. This pollutes the build directories,
as the files live in the same "name space" as the real output files,
messing with TAB completion among other things.
Hide the disgusting turds by placing the
The header tests track whether headers have been checked using empty
*.hdrtest files in the build tree. This pollutes the build directories,
as the files live in the same "name space" as the real output files,
messing with TAB completion among other things.
Hide the disgusting turds by placing the
The header tests track whether headers have been checked using empty
*.hdrtest files in the build tree. This pollutes the build directories,
as the files live in the same "name space" as the real output files,
messing with TAB completion among other things.
Hide the disgusting turds by placing the
Hide all the disgusting turds in .hdrtest subdirectories in the build
tree, and put the extra drm build-time checks behind a kconfig option.
BR,
Jani.
Cc: linux-kbu...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: intel...@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
Cc:
On 3/21/2025 9:36 PM, Nemesa Garg wrote:
register
I think this is part of the subject, need to fix this.
The strength value for sharpness is based on user input and
the winsize is based on resolution. Set the casf_enable flag
if there is a platform support and uapi strength is not zero.
O
drm_dp_dpcd_write_data() can be used to write the GUID for a non-root
MST branch device, similarly to writing the GUID to a root MST branch
device, do so.
Cc: Dmitry Baryshkov
Cc: Lyude Paul
Signed-off-by: Imre Deak
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 17 +++--
1 fi
On Sun, 30 Mar 2025, Zhenyu Wang wrote:
> On Thu, Mar 27, 2025 at 02:47:39PM +0200, Jani Nikula wrote:
>> Initializing const char opregion_signature[16] = OPREGION_SIGNATURE
>> (which is "IntelGraphicsMem") drops the NUL termination of the
>> string. This is intentional, but the compiler doesn't k
On 01.04.25 10:46, Jani Nikula wrote:
> On Mon, 31 Mar 2025, Thorsten Leemhuis wrote:
>> On 10.03.25 23:23, Kees Cook wrote:
>>> When a character array without a terminating NUL character has a static
>>> initializer, GCC 15's -Wunterminated-string-initialization will only
>>> warn if the array la
On Mon, 31 Mar 2025, Jouni Högander wrote:
> We are seeing timeouts in opening CRC fd when testing on setup where DP
> Panel Replay can be enabled. Fix these by checking if CRC is enabled for DP
> Panel Replay as well.
>
> Signed-off-by: Jouni Högander
Reviewed-by: Jani Nikula
> ---
> driver
On Sun, 30 Mar 2025, Zhenyu Wang wrote:
> On Fri, Mar 21, 2025 at 02:51:14PM +0200, Jani Nikula wrote:
>> Usually I'd argue hardcoding values is the wrong thing to do, but in
>> this case, GVT looking deep into the guts of the DPLL manager for the
>> reference clocks is worse. This is done for BDW
On Fri, 28 Mar 2025, Rodrigo Vivi wrote:
> On Wed, Mar 26, 2025 at 01:54:52PM +0200, Jani Nikula wrote:
>> Forward declare struct drm_printer instead of including drm/drm_print.h,
>> as we only need the pointer. Turns out quite a few places depend on this
>> include implicitly. Make them explicit.
On Mon, 31 Mar 2025, Thorsten Leemhuis wrote:
> On 10.03.25 23:23, Kees Cook wrote:
>> When a character array without a terminating NUL character has a static
>> initializer, GCC 15's -Wunterminated-string-initialization will only
>> warn if the array lacks the "nonstring" attribute[1]. Mark the a
Hi Anirban,
On Fri, Mar 28, 2025 at 12:49:24AM +0530, Sk Anirban wrote:
> Revise the power measurement logic to save and evaluate energy values.
How is the logic been revised? Can you be more specific please?
> Previously, the test only checked whether the system had entered the RC6
> state, wit
68 matches
Mail list logo
