linux.git/drivers/gpu/drm/xe/display, branch v6.9

drm/xe: Fix bo leak in intel_fb_bo_framebuffer_init

2024-04-17T13:03:06+00:00

Add a unreference bo in the error path, to prevent leaking a bo ref.

Return 0 on success to clarify the success path.

Signed-off-by: Maarten Lankhorst 
Fixes: 44e694958b95 ("drm/xe/display: Implement display support")
Cc:  # v6.8+
Reviewed-by: Nirmoy Das 
Link: https://patchwork.freedesktop.org/patch/msgid/20240404090302.68422-1-maarten.lankhorst@linux.intel.com
(cherry picked from commit a2f3d731be3893e730417ae3190760fcaffdf549)
Signed-off-by: Lucas De Marchi

drm/xe/display: Fix double mutex initialization

2024-04-11T13:41:53+00:00

All of these mutexes are already initialized by the display side since
commit 3fef3e6ff86a ("drm/i915: move display mutex inits to display
code"), so the xe shouldn´t initialize them.

Fixes: 44e694958b95 ("drm/xe/display: Implement display support")
Cc: Jani Nikula 
Cc: Arun R Murthy 
Reviewed-by: Jani Nikula 
Link: https://patchwork.freedesktop.org/patch/msgid/20240405200711.2041428-1-lucas.demarchi@intel.com
Signed-off-by: Lucas De Marchi 
(cherry picked from commit 117de185edf2c5767f03575219bf7a43b161ff0d)
Signed-off-by: Lucas De Marchi

Merge drm/drm-next into drm-xe-next

2024-02-20T17:57:17+00:00

Bring changes from drm-misc-next that got merged in drm-next back to
drm-xe so they can be used for additional features.

Signed-off-by: Lucas De Marchi

drm/i915: Try to relocate the BIOS fb to the start of ggtt

2024-02-07T00:01:49+00:00

On MTL the GOP (for whatever reason) likes to bind its framebuffer
high up in the ggtt address space. This can conflict with whatever
ggtt_reserve_guc_top() is trying to do, and the result is that
ggtt_reserve_guc_top() fails and then we proceed to explode when
trying to tear down the driver. Thus far I haven't analyzed what
causes the actual fireworks, but it's not super important as even
if it didn't explode we'd still fail the driver load and the user
would be left with an unusable GPU.

To remedy this (without having to figure out exactly what
ggtt_reserve_guc_top() is trying to achieve) we can attempt to
relocate the BIOS framebuffer to a lower ggtt address. We can do
this at this early point in driver init because nothing else is
supposed to be clobbering the ggtt yet. So we simply change where
in the ggtt we pin the vma, the original PTEs will be left as is,
and the new PTEs will get written with the same dma addresses.
The plane will keep on scanning out from the original PTEs until
we are done with the whole process, and at that point we rewrite
the plane's surface address register to point at the new ggtt
address.

Since we don't need a specific ggtt address for the plane
(apart from needing it to land in the mappable region for
normal stolen objects) we'll just try to pin it without a fixed
offset first. It should end up at the lowest available address
(which really should be 0 at this point in the driver init).
If that fails we'll fall back to just pinning it exactly to the
origianal address.

To make sure we don't accidentlally pin it partially over the
original ggtt range (as that would corrupt the original PTEs)
we reserve the original range temporarily during this process.

v2: Try to pin explicitly to ggtt offset 0 as otherwise DG2 puts it
even higher (atm we have no PIN_LOW flag to force it low)
v3: "fix" xe

Reviewed-by: Andrzej Hajda
Tested-by: Paz Zcharya
Signed-off-by: Ville Syrjälä
Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-16-ville.syrjala@linux.intel.com
Acked-by: Lucas De Marchi

drm/i915: Tweak BIOS fb reuse check

2024-02-07T00:01:44+00:00

Currently we assume that we bind the BIOS fb exactly into the same
ggtt address where the BIOS left it. That is about to change, and
in order to keep intel_reuse_initial_plane_obj() working as intended
we need to compare the original ggtt offset (called 'base' here)
as opposed to the actual vma ggtt offset we selected. Otherwise
the first plane could change the ggtt offset, and then subsequent
planes would no longer notice that they are in fact using the same
ggtt offset that the first plane was already using. Thus the reuse
check will fail and we proceed to turn off these subsequent planes.

TODO: would probably make more sense to do the pure readout first
for all the planes, then check for fb reuse, and only then proceed
to pin the object into the final location in the ggtt...

v2: "fix" xe

Reviewed-by: Andrzej Hajda 
Tested-by: Paz Zcharya 
Signed-off-by: Ville Syrjälä 
Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-15-ville.syrjala@linux.intel.com
Acked-by: Lucas De Marchi

drm/i915: Simplify intel_initial_plane_config() calling convention

2024-02-07T00:01:36+00:00

There's no reason the caller of intel_initial_plane_config() should
have to loop over the CRTCs. Pull the loop into the function to
make life simpler for the caller.

v2: "fix" xe

Reviewed-by: Andrzej Hajda 
Tested-by: Paz Zcharya 
Signed-off-by: Ville Syrjälä 
Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-13-ville.syrjala@linux.intel.com
Acked-by: Lucas De Marchi

drm/xe/display: Fix memleak in display initialization

2024-02-03T06:05:07+00:00

intel_power_domains_init is called twice in xe_device_probe:

1) intel_power_domains_init()
   xe_display_init_nommio()
   xe_device_probe()

2) intel_power_domains_init()
   intel_display_driver_probe_noirq()
   xe_display_init_noirq()
   xe_device_probe()

It needs remove one to avoid power_domains->power_wells double malloc.

unreferenced object 0xffff88811150ee00 (size 512):
  comm "systemd-udevd", pid 506, jiffies 4294674198 (age 3605.560s)
  hex dump (first 32 bytes):
    10 b4 9d a0 ff ff ff ff ff ff ff ff ff ff ff ff  ................
    ff ff ff ff ff ff ff ff 00 00 00 00 00 00 00 00  ................
  backtrace:
    [] __kmem_cache_alloc_node+0x1c1/0x2b0
    [] __kmalloc+0x52/0x150
    [] __set_power_wells+0xc3/0x360 [xe]
    [] xe_display_init_nommio+0x4c/0x70 [xe]
    [] xe_device_probe+0x3c/0x5a0 [xe]
    [] xe_pci_probe+0x33f/0x5a0 [xe]
    [] local_pci_probe+0x47/0xa0
    [] pci_device_probe+0xc3/0x1f0
    [] really_probe+0x1a2/0x410
    [] __driver_probe_device+0x78/0x160
    [] driver_probe_device+0x1e/0x90
    [] __driver_attach+0xda/0x1d0
    [] bus_for_each_dev+0x7c/0xd0
    [] bus_add_driver+0x119/0x220
    [] driver_register+0x60/0x120
    [] 0xffffffffa05e50a0

The call to intel_power_domains_cleanup() needs to stay where it is for
now. The main issue is that while the init is called by the display
side, shared by i915 and xe, the cleanup is called by a non-shared code
path. Fixing that will be done as a separate commit.

Fixes: 44e694958b95 ("drm/xe/display: Implement display support")
Signed-off-by: Xiaoming Wang 
[ reword commit message and explain why the fini needs to stay
  where it is ]
Reviewed-by: Lucas De Marchi 
Signed-off-by: Lucas De Marchi 
Link: https://patchwork.freedesktop.org/patch/msgid/20240202215658.561298-1-lucas.demarchi@intel.com

drm/xe: move xe_display.[ch] under display/

2024-01-31T12:58:40+00:00

All the other display related files are under display/ subdirectory,
also move xe_display.[ch] there.

Sort the build list while at it.

Signed-off-by: Jani Nikula 
Reviewed-by: Rodrigo Vivi 
Acked-by: Lucas De Marchi 
Link: https://patchwork.freedesktop.org/patch/msgid/20240122101428.2683468-1-jani.nikula@intel.com

drm/xe/display: Fix dummy __i915_inject_probe_error()

2023-12-21T16:46:17+00:00

When CONFIG_DRM_I915_DEBUG is not set, a dummy
__i915_inject_probe_error() is provided on the xe side. Use the same
logic as in drivers/gpu/drm/i915/i915_utils.c to ifdef it out. This
fixes the build with W=1 and without that config:

	  CC [M]  drivers/gpu/drm/xe/display/ext/i915_utils.o
	../drivers/gpu/drm/xe/display/ext/i915_utils.c:19:5: error: no previous prototype for ‘__i915_inject_probe_error’ [-Werror=missing-prototypes]
	   19 | int __i915_inject_probe_error(struct drm_i915_private *i915, int err,
	      |     ^~~~~~~~~~~~~~~~~~~~~~~~~

Signed-off-by: Lucas De Marchi 
Reviewed-by: Rodrigo Vivi 
Signed-off-by: Rodrigo Vivi

drm/xe/dsb: DSB implementation for xe

2023-12-21T16:45:10+00:00

Add xe specific DSB buffer handling methods.

v1: Initial version.
v2: Add null check after dynamic memory allocation of vma. [Uma]

Reviewed-by: Uma Shankar 
Signed-off-by: Animesh Manna 
Signed-off-by: Rodrigo Vivi