The DRM buddy allocator is a shared DRM memory management
component used by multiple DRM drivers.
Matthew Auld and Arun Pravin have been actively involved in
maintaining this code, including patch review and functional
changes.
Add a dedicated MAINTAINERS entry to reflect the current
maintainership.
v2: Include drivers/gpu/drm/tests/drm_buddy_test.c file (Matthew).
Signed-off-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com>
Acked-by: Matthew Auld <matthew.auld@intel.com>
Acked-by: Christian König <christian.koenig@amd.com>
Link: https://patch.msgid.link/20260112114022.315139-1-Arunpravin.PaneerSelvam@amd.com
Fix all kernel-doc warnings in rocket_accel.h:
Warning: include/uapi/drm/rocket_accel.h:35 Incorrect use of kernel-doc
format: * Output: DMA address for the BO in the NPU address space.
This address
and 22 warnings like these:
Warning: include/uapi/drm/rocket_accel.h:43 struct member 'size'
not described in 'drm_rocket_create_bo'
Warning: include/uapi/drm/rocket_accel.h:60 struct member 'handle'
not described in 'drm_rocket_prep_bo'
Warning: include/uapi/drm/rocket_accel.h:73 struct member 'handle'
not described in 'drm_rocket_fini_bo'
Warning: include/uapi/drm/rocket_accel.h:86 struct member 'regcmd'
not described in 'drm_rocket_task'
Warning: include/uapi/drm/rocket_accel.h:116 struct member 'tasks'
not described in 'drm_rocket_job'
Warning: include/uapi/drm/rocket_accel.h:135 struct member 'jobs'
not described in 'drm_rocket_submit'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Tomeu Vizoso <tomeu@tomeuvizoso.net>
Signed-off-by: Tomeu Vizoso <tomeu@tomeuvizoso.net>
Link: https://patch.msgid.link/20251023062440.4093661-1-rdunlap@infradead.org
There already is a function to return the offset of the core for a given
struct device, so let's reuse that function instead of reimplementing
the same logic.
There's one change in behavior when a struct device is passed which
doesn't match any core's. Before, we would continue through
rocket_remove() but now we exit early, to match what other callers of
find_core_for_dev() (rocket_device_runtime_resume/suspend()) are doing.
This however should never happen. Aside from that, no intended change in
behavior.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Tomeu Vizoso <tomeu@tomeuvizoso.net>
Signed-off-by: Tomeu Vizoso <tomeu@tomeuvizoso.net>
Link: https://patch.msgid.link/20251215-rocket-reuse-find-core-v1-1-be86a1d2734c@cherry.de
When rocket_job_init() is called, iommu_group_get() has already been
called, therefore we should call iommu_group_put() and make the
iommu_group pointer NULL. This aligns with what's done in
rocket_core_fini().
If pm_runtime_resume_and_get() somehow fails, not only should
rocket_job_fini() be called but we should also unwind everything done
before that, that is, disable PM, put the iommu_group, NULLify it and
then call rocket_job_fini(). This is exactly what's done in
rocket_core_fini() so let's call that function instead of duplicating
the code.
Fixes: 0810d5ad88 ("accel/rocket: Add job submission IOCTL")
Cc: stable@vger.kernel.org
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Tomeu Vizoso <tomeu@tomeuvizoso.net>
Signed-off-by: Tomeu Vizoso <tomeu@tomeuvizoso.net>
Link: https://patch.msgid.link/20251215-rocket-error-path-v1-1-eec3bf29dc3b@cherry.de
Add support for the dw-hdmi-qp driver to handle devices with missing
HPD pins.
Since in this situation we are now polling for the EDID data via i2c
change the error message to a rate limited debug message when we are
unable to complete an i2c read, as a disconnected device would
otherwise fill dmesg with i2c read errors.
Reviewed-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20251119225526.70588-3-macroalpha82@gmail.com
Add an attribute of "no-hpd" for the Rockchip dw-hdmi-qp controller.
This is used to describe implementations where the HPD pin is not
connected or used for other purposes, such as in the RK3588S based
Gameforce Ace which repurposed the GPIO for an additional face
button.
The "no-hpd" option was chosen to be consistent with other devices
which already define this parameter for broken or missing hpd
functionality.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20251119225526.70588-2-macroalpha82@gmail.com
Currently if a user enqueue a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.
This lack of consistency cannot be addressed without refactoring the API.
system_wq should be the per-cpu workqueue, yet in this name nothing makes
that clear, so replace system_wq with system_percpu_wq.
The old wq (system_wq) will be kept for a few release cycles.
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20251031104846.119503-3-marco.crivellari@suse.com
Currently if a user enqueue a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.
This lack of consistency cannot be addressed without refactoring the API.
system_unbound_wq should be the default workqueue so as not to enforce
locality constraints for random work whenever it's not required.
Adding system_dfl_wq to encourage its use when unbound work should be used.
The old system_unbound_wq will be kept for a few release cycles.
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20251031104846.119503-2-marco.crivellari@suse.com
On the RK3506 platform, there is no iommu hardware. And even on
platform that have iommu hardware, it should be possible to use
VOP without enabling iommu. In this case, a contiguous memory
space like CMA should be used.
So this patch removes the dependency on ROCKCHIP_IOMMU
with an 'optional-dependency'.
Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com>
[added reference to optional-dependies description]
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20251106020632.92-9-kernel@airkyi.com
If a user has set an invalid CONFIG_DRM_PANIC_SCREEN value (such as
"qr_code" without CONFIG_DRM_PANIC_SCREEN_QR_CODE=y due to missing or
incorrect Rust dependencies), there is a panic when accessing
/sys/module/drm/parameters/panic_screen:
[ 12.218375] BUG: unable to handle page fault for address: 0000000796dd8818
[ 12.219737] #PF: supervisor read access in kernel mode
...
[ 12.227167] RIP: 0010:drm_panic_type_get+0x1b/0x30
If drm_panic_type_set() does not find a valid drm_panic_type enumeration
in drm_panic_type_map based on the provided value, it does not change
drm_panic_type from the default -1 value, which is not a valid index for
accessing drm_panic_type_map in drm_panic_type_get(), resulting in the
crash.
Validate the value of CONFIG_DRM_PANIC_SCREEN at boot time via the
return value of drm_panic_type_set() in drm_panic_init() and explicitly
fall back to the default of "user" with a message to the user so that
they can adjust their configuration or fix missing dependencies.
[ 0.800697] Unsupported value for CONFIG_DRM_PANIC_SCREEN ('qr_code'), falling back to 'user'...
Fixes: e85e9ccf3f ("drm/panic: Report invalid or unsupported panic modes")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
Link: https://lore.kernel.org/r/20260105-drm_panic-handle-invalid-drm_panic_screen-v1-1-55228bd4b0f8@kernel.org
The latest firmware requires the message DMA buffer to
- have a minimum size of 8K
- use a power-of-two size
- be aligned to the buffer size
- not cross 64M boundary
Update the buffer allocation logic to meet these requirements and support
the latest firmware.
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Signed-off-by: Lizhi Hou <lizhi.hou@amd.com>
Link: https://patch.msgid.link/20251219014356.2234241-1-lizhi.hou@amd.com
In commit 9ce4aef9a5 ("drm/gpuvm: take GEM lock inside
drm_gpuvm_bo_obtain_prealloc()") we update
drm_gpuvm_bo_obtain_prealloc() to take locks internally, which means
that it's only usable in immediate mode.
In this commit, we notice that drm_gpuvm_bo_obtain() requires you to use
staged mode. This means that we now have one variant of obtain for each
mode you might use gpuvm in.
To reflect this information, we add a warning about using it in
immediate mode, and to make the distinction clearer we rename the method
with a _locked() suffix so that it's clear that it requires the caller
to take the locks.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260108-gpuvm-rust-v2-2-dbd014005a0b@google.com
[ Slightly reword commit message to refer to commit 9ce4aef9a5
("drm/gpuvm: take GEM lock inside drm_gpuvm_bo_obtain_prealloc()").
- Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Starting from NPU6, the driver can pass boot parameters address through
the AON retention register and toggle between cold/warm boot types using
the boot_type parameter, while setting the cold boot entry point in both
cases.
Refactor the existing cold/warm boot handling to be consistent with the
new NPU6 boot flow requirements and still maintain compatibility with
older boot flows.
This will allow firmware to remove support for legacy warm boot starting
from NPU6.
Fixes: 550f4dd2ce ("accel/ivpu: Add support for Nova Lake's NPU")
Signed-off-by: Karol Wachowski <karol.wachowski@linux.intel.com>
Reviewed-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com>
Reviewed-by: Andrzej Kacprowski <andrzej.kacprowski@linux.intel.com>
Signed-off-by: Maciej Falkowski <maciej.falkowski@linux.intel.com>
Link: https://patch.msgid.link/20251230142116.540026-1-maciej.falkowski@linux.intel.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>
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
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
