UAPI Changes:
Cross-subsystem Changes:
Core Changes:
- draw: Add API to check if a format conversion can be done
- panic: Rename draw_panic_static_* to draw_panic_screen_*, Add kunit
tests
- shmem: Improve tests
Driver Changes:
- ast: Big endian fixes
- etnaviv: Add PPU flop reset support
- panfrost: Add GPU_PM_RT support for RZ/G3E SoC
- panthor: multiple fixes around VM termination, huge page support
- pl111: Fix build regression
- v3d: Fix DMA segment size
- bridge:
- Add connector argument to .hpd_notify
- Plenty of patches to convert existing drivers to refcounting
- Convert Rockchip's inno hdmi support to a proper bridge
- lontium-lt9611uxc: Switch to HDMI audio helpers
- panel:
- New panel: BOE NV140WUM-T08
-----BEGIN PGP SIGNATURE-----
iJUEABMJAB0WIQTkHFbLp4ejekA/qfgnX84Zoj2+dgUCaV9qAAAKCRAnX84Zoj2+
duxGAX4vPiNmTlX8Sh0cTPW0eOUtHCBc2kf1TdWPmczCWeF9PVuMICCWYfhgWaJf
d7yTLaQBfiniO/x1+uUx5izUVrdVbyp6i9ZooijwBOn2cvxZuW2UT0/1I6040L1G
T+vcJsmJoA==
=l26/
-----END PGP SIGNATURE-----
Merge tag 'drm-misc-next-2026-01-08' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-next
drm-misc-next for 6.20:
UAPI Changes:
Cross-subsystem Changes:
Core Changes:
- draw: Add API to check if a format conversion can be done
- panic: Rename draw_panic_static_* to draw_panic_screen_*, Add kunit
tests
- shmem: Improve tests
Driver Changes:
- ast: Big endian fixes
- etnaviv: Add PPU flop reset support
- panfrost: Add GPU_PM_RT support for RZ/G3E SoC
- panthor: multiple fixes around VM termination, huge page support
- pl111: Fix build regression
- v3d: Fix DMA segment size
- bridge:
- Add connector argument to .hpd_notify
- Plenty of patches to convert existing drivers to refcounting
- Convert Rockchip's inno hdmi support to a proper bridge
- lontium-lt9611uxc: Switch to HDMI audio helpers
- panel:
- New panel: BOE NV140WUM-T08
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Maxime Ripard <mripard@redhat.com>
Link: https://patch.msgid.link/20260108-literate-nyala-of-courtesy-de501a@houat
v2: Check for feature PIPE_3D when forcing PPU flop reset (Lucas)
v3: - drop use of ppu_flop_reset enum (Christian Gmeiner)
- don't initialize module parameter to zero (checkpatch)
- avoid multi-line string in warning message (checkpatch)
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Tested-by: Marek Vasut <marek.vasut@mailbox.org> # STM32MP255C DHCOS DHSBC
Link: https://patch.msgid.link/20251119164624.9297-6-gert.wollny@collabora.com
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
The PPU flop reset is required on some hardware to clear the
temporary registers. This code follows the implementation
of the PPU flop reset as found in the public galcore kernel
module. Compared to that code some superfluous parts were
removed and only the code path for SoC chip_model = 0x8000
and revision = 0x6205 is implemented and tested.
v2: - Move flop reset data to etnaviv_drm_private and initialize it
from etnaviv_gpu_bind (Lucas)
- Prepare code for more chip IDs and other flop reset types
- Do some cleanups and rename some functions
v3: - Move initialization of flop reset data to etnaviv_gpu_init (Lucas)
- Free PPU data suballocation (Lucas)
v4: As suggested by
- replace "asm-generic/int-ll64.h" with "linux/types.h"
- drop flop reset type enum since we only support one type here
- move function return parameters on same line with function name
- replace open coded for loop with memset32
- add cnost to local static values
- add a return value to etnaviv_flop_reset_ppu_init; handle and
pass errors on to the caller
- handle etnaviv_flop_reset_ppu_init return value
- use dev_err for flop reset error message
- fix include guard to be consistent with the other driver code
- fix license header and formatting
v5: As suggested by Christian Gmeiner:
- add required header that is no longer pulled in by etnaviv_buffer.h
- fix include style of linux headers
- free flop_reset_data_ppu when command buffer initialization fails
- fix typo in error message
[cgmeiner: fix SPDX comment style, fix line end with a '(' and fix typo]
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Tested-by: Marek Vasut <marek.vasut@mailbox.org> # STM32MP255C DHCOS DHSBC
Link: https://patch.msgid.link/20251119164624.9297-5-gert.wollny@collabora.com
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
v2: move some defines that resided in etnaviv_flop_reset.c
into the header as well
v3: fix spacing/tab stops
[cgmeiner: remove use of multiple blank lines]
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Tested-by: Marek Vasut <marek.vasut@mailbox.org> # STM32MP255C DHCOS DHSBC
Link: https://patch.msgid.link/20251119164624.9297-2-gert.wollny@collabora.com
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Commit 5d0bfe4484 ("drm/meson: Add HDMI 1.4 4k modes") added support
for HDMI 1.4 4k modes, which is what TVs need. For computer monitors
the code is using the DMT code-path, which ends up in
meson_venc_hdmi_supported_mode(), which does not allow the 4k modes yet.
The datasheet for all supported SoCs mentions "4Kx2K@60". It's not
clear whether "4K" here means 3840 or 4096 pixels.
Allow resolutions up to 3840x2160 pixels (including middle steps, such
as WQHD at 2560x1440 pixels) so they can be used with computer monitors
(using the DMT code-path in the driver).
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Acked-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20251108134236.1299630-1-martin.blumenstingl@googlemail.com
Add kunit tests for drm_panic.
They check that drawing the panic screen doesn't crash, but they
don't check the correctness of the resulting image.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20251216082524.115980-3-jfalempe@redhat.com
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
I called them "static" because the panic screen is drawn only once,
but this can be confused with the static meaning in C.
Also remove some unnecessary braces in draw_panic_dispatch().
No functionnal change.
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patch.msgid.link/20251216082524.115980-2-jfalempe@redhat.com
Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
The drm_info() function requires the drm/drm_print.h header to be included
first:
In file included from drivers/gpu/drm/pl111/pl111_nomadik.c:7:
drivers/gpu/drm/pl111/pl111_nomadik.h:11:32: error: 'struct drm_device' declared inside parameter list will not be visible outside of this definition or declaration [-Werror]
11 | void pl111_nomadik_init(struct drm_device *dev);
| ^~~~~~~~~~
drivers/gpu/drm/pl111/pl111_nomadik.c: In function 'pl111_nomadik_init':
drivers/gpu/drm/pl111/pl111_nomadik.c:34:9: error: implicit declaration of function 'drm_info'; did you mean 'pr_info'? [-Wimplicit-function-declaration]
34 | drm_info(dev, "set Nomadik PMU mux to CLCD mode\n");
| ^~~~~~~~
| pr_info
Fixes: a1542b8ca6 ("drm: pl111: replace dev_* print functions with drm_* variants")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Eslam Khafagy <eslam.medhat1993@gmail.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20251223214915.503913-1-arnd@kernel.org
imx8qxp_pixel_link_find_next_bridge() already emits a DRM_DEV_ERROR() on
error except for -EPROBE_DEFER. The caller emits another one, which is
redundant. Remove the message in the caller and keep the one in
imx8qxp_pixel_link_find_next_bridge() as it is more informative about the
error cause.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20251216-drm-bridge-alloc-getput-drm_of_find_bridge-v3-20-b5165fab8058@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
This driver obtains a bridge pointer from of_drm_find_bridge() in the probe
function and stores it until driver removal. of_drm_find_bridge() is
deprecated. Move to of_drm_find_and_get_bridge() for the bridge to be
refcounted and use the destroy hook to put the reference on deallocation.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20251216-drm-bridge-alloc-getput-drm_of_find_bridge-v3-17-b5165fab8058@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
This driver obtains a bridge pointer from of_drm_find_bridge() in the probe
function and stores it until driver removal. of_drm_find_bridge() is
deprecated. Move to of_drm_find_and_get_bridge() for the bridge to be
refcounted and use bridge->next_bridge to put the reference on
deallocation.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20251216-drm-bridge-alloc-getput-drm_of_find_bridge-v3-16-b5165fab8058@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
In preparation for using bridge->next_bridge, we need to ensure that it
will never contain anything but NULL or a valid bridge pointer. Current
code stores an ERR_PTR when imx8qxp_pxl2dpi_find_next_bridge() errors
out. Instead of fixing that after the facts in the caller, change the
function to internally set the next_pointer and just return an int error
value.
No functional changes.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20251216-drm-bridge-alloc-getput-drm_of_find_bridge-v3-15-b5165fab8058@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
imx8qxp_pxl2dpi_find_next_bridge() already emits a DRM_DEV_ERROR() for
every error except -EPROBE_DEFER. The caller emits another one, which is
redundant. Remove the message in the caller and keep the two in
imx8qxp_pxl2dpi_find_next_bridge() as they are more informative about the
error cause.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20251216-drm-bridge-alloc-getput-drm_of_find_bridge-v3-14-b5165fab8058@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
This driver obtains a bridge pointer from of_drm_find_bridge() in the probe
function and stores it until driver removal. of_drm_find_bridge() is
deprecated. Move to of_drm_find_and_get_bridge() for the bridge to be
refcounted and use bridge->next_bridge to put the reference on
deallocation.
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Tested-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20251216-drm-bridge-alloc-getput-drm_of_find_bridge-v3-12-b5165fab8058@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
This driver obtains a bridge pointer from of_drm_find_bridge() in the probe
function and stores it until driver removal. of_drm_find_bridge() is
deprecated. Move to of_drm_find_and_get_bridge() for the bridge to be
refcounted and use bridge->next_bridge to put the reference on
deallocation.
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20251216-drm-bridge-alloc-getput-drm_of_find_bridge-v3-11-b5165fab8058@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
This driver obtains a bridge pointer from of_drm_find_bridge() in the probe
function and stores it until driver removal. of_drm_find_bridge() is
deprecated. Move to of_drm_find_and_get_bridge() for the bridge to be
refcounted and use bridge->next_bridge to put the reference on
deallocation.
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20251216-drm-bridge-alloc-getput-drm_of_find_bridge-v3-10-b5165fab8058@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
This driver obtains a bridge pointer from of_drm_find_bridge() in the probe
function and stores it until driver removal. of_drm_find_bridge() is
deprecated. Move to of_drm_find_and_get_bridge() for the bridge to be
refcounted and use bridge->next_bridge to put the reference on
deallocation.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20251216-drm-bridge-alloc-getput-drm_of_find_bridge-v3-9-b5165fab8058@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
This driver obtains a bridge pointer from of_drm_find_bridge() in the probe
function and stores it until driver removal. of_drm_find_bridge() is
deprecated. Move to of_drm_find_and_get_bridge() for the bridge to be
refcounted and use bridge->next_bridge to put the reference on
deallocation.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20251216-drm-bridge-alloc-getput-drm_of_find_bridge-v3-8-b5165fab8058@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
This driver obtains a bridge pointer from of_drm_find_bridge() in the probe
function and stores it until driver removal. of_drm_find_bridge() is
deprecated. Move to of_drm_find_and_get_bridge() for the bridge to be
refcounted and use bridge->next_bridge to put the reference on
deallocation.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20251216-drm-bridge-alloc-getput-drm_of_find_bridge-v3-7-b5165fab8058@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Many bridge drivers store a next_bridge pointer in their private data and
use it for attach and sometimes other purposes. This is going to be risky
when bridge hot-unplug is used.
Considering this example scenario:
1. pipeline: encoder --> bridge A --> bridge B --> bridge C
2. encoder takes a reference to bridge B
3. bridge B takes a next_bridge reference to bridge C
4. encoder calls (bridge B)->b_foo(), which in turns references
next_bridge, e.g.:
b_foo() {
bar(b->next_bridge);
}
If bridges B and C are removed, bridge C can be freed but B is still
allocated because the encoder holds a reference to B. So when step 4
happens, 'b->next-bridge' would be a use-after-free.
Calling drm_bridge_put() in the B bridge .remove function does not solve
the problem as it leaves a (potentially long) risk window between B removal
and the final deallocation of B. A safe moment to put the B reference is in
__drm_bridge_free(), when the last reference has been put. This can be done
by drivers in the .destroy func. However to avoid the need for so many
drivers to implement a .destroy func, just offer a next_bridge pointer to
all bridges that is automatically put it in __drm_bridge_free(), exactly
when the .destroy func is called.
Suggested-by: Maxime Ripard <mripard@kernel.org>
Link: https://lore.kernel.org/all/20251201-thick-jasmine-oarfish-1eceb0@houat/
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20251216-drm-bridge-alloc-getput-drm_of_find_bridge-v3-6-b5165fab8058@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
of_drm_find_bridge() does not increment the refcount for the returned
bridge, but that is required now. However converting it and all its users
is not realistically doable at once given the large amount of (direct and
indirect) callers and the complexity of some.
Solve this issue by creating a new of_drm_find_and_get_bridge() function
that is identical to of_drm_find_bridge() except also it takes a
reference. Then of_drm_find_bridge() will be deprecated to be eventually
removed.
Suggested-by: Maxime Ripard <mripard@kernel.org>
Link: https://lore.kernel.org/dri-devel/20250319-stylish-lime-mongoose-0a18ad@houat/
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20251216-drm-bridge-alloc-getput-drm_of_find_bridge-v3-1-b5165fab8058@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
- Switch to use kernel standard fault injection in i915 (Juha-Pekka)
Display uAPI related:
- Display uapi vs. hw state fixes (Ville)
- Expose sharpness only if num_scalers is >= 2 (Nemesa)
Display related:
- More display driver refactor and clean-ups, specially towards separation (Jani)
- Add initial support Xe3p_LPD for NVL (Gustavo, Sai, )
- BMG FBC W/a (Vinod)
- RPM fix (Dibin)
- Add MTL+ platforms to support dpll framework (Mika, Imre)
- Other PLL related fixes (Imre)
- Fix DIMM_S DRAM decoding on ICL (Ville)
- Async flip refactor (Ville, Jouni)
- Go back to using AUX interrupts (Ville)
- Reduce severity of failed DII FEC enabling (Grzelak)
- Enable system cache support for FBC (Vinod)
- Move PSR/Panel Replay sink data into intel_connector and other PSR changes (Jouni)
- Detect AuxCCS support via display parent interface (Tvrtko)
- Clean up link BW/DSC slice config computation(Imre)
- Toggle powerdown states for C10 on HDMI (Gustavo)
- Add parent interface for PC8 forcewake tricks (Ville)
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEbSBwaO7dZQkcLOKj+mJfZA7rE8oFAmlFtn0ACgkQ+mJfZA7r
E8p8Awf9F/V7qCk8evJJV4gzj1OuUIf7vrn4+tHbRamx8iOSXNdwCJQLC0JRM5BM
VCmHpyVEDjHdFvDKPefk5fznDs/OEOH3HHIzNztggj4/gFpOBLlPtW1fwdm82qS2
J+1HedK66BwJSkbFdkdGAnWnkL+Uc/LcaMCPZlOU/F94Gqx61w47omRNaO0nf09f
k3AFO8piUQjZdsrWdIdVcCvJ9iZ7jjbXhPlYlUpLmrbAaDDLt1EvgR2lHDeH2v66
drFQ2CIPpidnY+qPiSr+SgQCapVQeVf9e8+MvLRDuBrIp9g+T9xU2L1ZYLOMjByE
hSlB6C07I2oppD2cd8XVk2vbLSAl0w==
=MtQI
-----END PGP SIGNATURE-----
Merge tag 'drm-intel-next-2025-12-19' of https://gitlab.freedesktop.org/drm/i915/kernel into drm-next
Beyond Display related:
- Switch to use kernel standard fault injection in i915 (Juha-Pekka)
Display uAPI related:
- Display uapi vs. hw state fixes (Ville)
- Expose sharpness only if num_scalers is >= 2 (Nemesa)
Display related:
- More display driver refactor and clean-ups, specially towards separation (Jani)
- Add initial support Xe3p_LPD for NVL (Gustavo, Sai, )
- BMG FBC W/a (Vinod)
- RPM fix (Dibin)
- Add MTL+ platforms to support dpll framework (Mika, Imre)
- Other PLL related fixes (Imre)
- Fix DIMM_S DRAM decoding on ICL (Ville)
- Async flip refactor (Ville, Jouni)
- Go back to using AUX interrupts (Ville)
- Reduce severity of failed DII FEC enabling (Grzelak)
- Enable system cache support for FBC (Vinod)
- Move PSR/Panel Replay sink data into intel_connector and other PSR changes (Jouni)
- Detect AuxCCS support via display parent interface (Tvrtko)
- Clean up link BW/DSC slice config computation(Imre)
- Toggle powerdown states for C10 on HDMI (Gustavo)
- Add parent interface for PC8 forcewake tricks (Ville)
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patch.msgid.link/aUW3bVDdE63aSFOJ@intel.com
Convert it to drm bridge driver, it will be convenient for us to
migrate the connector part to the display driver later.
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20251016083843.76675-2-andyshrk@163.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
While LT9611UXC is a DSI-to-HDMI bridge, it implements all HDMI-related
functions internally, in the firmware, thus it doesn't make sense to
implement DRM_BRIDGE_OP_HDMI. However it is possible to implement
DRM_BRIDGE_OP_HDMI_AUDIO, streamlining HDMI audio plumbing (which
includes plugged notifications and ELD handling).
Implement corresponding callbacks and trigger EDID read /
drm_connector_hdmi_audio_plugged_notify() from the hpd_notify callback.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20250803-lt9611uxc-hdmi-v1-2-cb9ce1793acf@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Drivers might need to update DRM connector in the
drm_bridge_funcs.hpd_notify callback (e.g. it might be necessary to
update EDID before setting ELD). Add corresponding argument to the
callback.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20250803-lt9611uxc-hdmi-v1-1-cb9ce1793acf@oss.qualcomm.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Some minor improvements to the log messages in the rebar logic:
use xe-oriented printk, switch unit from M to MiB in a few places for
consistency and use ilog2(SZ_1M) for clarity.
Suggested-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Suggested-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patch.msgid.link/20251219211650.1908961-6-matthew.d.roper@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Now that xe_pci.c calls the rebar directly, it doesn't make sense to
keep it in xe_vram.c since it's closer to the PCI initialization than to
the VRAM. Move it to its own file.
While at it, add a better comment to document the possible values for
the vram_bar_size module parameter.
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patch.msgid.link/20251219211650.1908961-5-matthew.d.roper@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Use READ_ONCE and WRITE_ONCE when operating on ct->state
to prevent the compiler form ignoring important modifications
to its value.
Suggested-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20251222201957.63245-6-jonathan.cavitt@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Use READ_ONCE and WRITE_ONCE when operating on g2h_fence->done
to prevent the compiler from ignoring important modifications
to its value.
Fixes: dd08ebf6c3 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
Suggested-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20251222201957.63245-5-jonathan.cavitt@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Since different drivers can use SoC remapper, modify VSEC code to
access SoC remapper via a helper that would synchronize such accesses.
Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Reviewed-by: Badal Nilawar <badal.nilawar@intel.com>
Link: https://patch.msgid.link/20251223183943.3175941-7-umesh.nerlige.ramappa@intel.com
SoC remapper is used to map different HW functions in the SoC to their
respective drivers. Initialize SoC remapper during driver load.
Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Reviewed-by: Badal Nilawar <badal.nilawar@intel.com>
Link: https://patch.msgid.link/20251223183943.3175941-6-umesh.nerlige.ramappa@intel.com
Building the XE driver through Yocto throws this QA warning:
WARNING: mc🏠linux-stable-6.17-r0 do_package_qa: QA Issue: File /usr/src/debug/linux-stable/6.17/drivers/gpu/drm/xe/generated/xe_device_wa_oob.h in package linux-stable-src contains reference to TMPDIR [buildpaths]
WARNING: mc🏠linux-stable-6.17-r0 do_package_qa: QA Issue: File /usr/src/debug/linux-stable/6.17/drivers/gpu/drm/xe/generated/xe_wa_oob.h in package linux-stable-src contains reference to TMPDIR [buildpaths]
...because the comment at the top of the generated header contains the
absolute path to the rules file at build time:
* This file was generated from rules: /home/calvinow/git/meta-house/build/tmp-house/work-shared/nuc14rvhu7/kernel-source/drivers/gpu/drm/xe/xe_device_wa_oob.rules
Fix this minor annoyance by putting the basename of the rules file in
the generated comment instead of the absolute path, so the generated
header contents no longer depend on the location of the kernel source.
Signed-off-by: Calvin Owens <calvin@wbinvd.org>
Link: https://patch.msgid.link/20251222165441.516102-2-rodrigo.vivi@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Commit 5488bec96b ("drm/xe/uapi: Use hint for guc to set GT frequency")
introduced low latency hint for use by user space when creating an exec
queue. This instructs SLPC to ramp the GT frequency aggressively.
SVM relies on an internal exec queue to migrate memory upon page faults.
This change creates this exec queue with the low latency hint to speed up
migration.
This should not impact systems where GT frequency is set over sysfs, or
with long running workloads which give enough time for the frequency to
ramp up. An example of memory access pattern that shows an improvement of
SVM performance is running hundreds of times IGT eu-fault-2m-once-device
in xe_exec_system_allocator. The copy duration provided by GT stats in
svm_2M_device_copy_us shows per GPU page fault:
~ 165 μs without low latency hint
~ 130 μs with low latency hint
Suggested-by: Matthew Brost <matthew.brost@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Francois Dugast <francois.dugast@intel.com>
Link: https://patch.msgid.link/20251223115327.49555-1-francois.dugast@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Introduce an rw-semaphore to serialize migration to device if
it's likely that migration races with another device migration
of the same CPU address space range.
This is a temporary fix to attempt to mitigate a livelock that
might happen if many devices try to migrate a range at the same
time, and it affects only devices using the xe driver.
A longer term fix is probably improvements in the core mm
migration layer.
Suggested-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://patch.msgid.link/20251219113320.183860-25-thomas.hellstrom@linux.intel.com
Support source interconnect migration by using the copy_to_ram() op
of the source device private pages.
Source interconnect migration is required to flush the L2 cache of
the source device, which among other things is a requirement for
correct global atomic operation. It also enables the source GPU to
potentially decompress any compressed content which is not
understood by peers, and finally for the PCIe case, it's expected
that writes over PCIe will be faster than reads.
The implementation can probably be improved by coalescing subregions
with the same source.
v5:
- Update waiting for the pre_migrate_fence and comments around that,
previously in another patch. (Himal).
- Actually select device private pages to migrate when
source_peer_migrates is true.
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> # For merging through drm-xe.
Link: https://patch.msgid.link/20251219113320.183860-24-thomas.hellstrom@linux.intel.com
