With gem objects in rust, the most ideal way for us to be able to handle
gem shmem object creation is to be able to handle the memory allocation of
a gem object ourselves - and then have the DRM gem shmem helpers initialize
the object we've allocated afterwards. So, let's split out
drm_gem_shmem_init() from drm_gem_shmem_create() to allow for doing this.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Link: https://lore.kernel.org/r/20250911230147.650077-2-lyude@redhat.com
Add support to register host1x devices without requiring subdevices.
This ensures syncpoint functionality remains available even when engine
subdevices are not present.
Add softdep for tegra-drm to make userspace interface available
without module autoloading through device tree entries.
Signed-off-by: Vamsee Vardhan Thummala <vthummala@nvidia.com>
[mperttunen@nvidia.com: some rewording]
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://lore.kernel.org/r/20250708-host1x-allow-no-subdevs-v1-1-93c66c251f03@nvidia.com
The current submission opcode sequence first takes the engine MLOCK,
and then switches to HOST1X class to wait prefences. This is fine
while we only use a single channel per engine and there is no
virtualization, since jobs are serialized on that one channel anyway.
However, when that assumption doesn't hold, we are keeping the
engine locked while not running anything on it while waiting for
prefences to complete.
To resolve this, execute wait commands in the beginning of the job
outside the engine MLOCK. We still take the HOST1X MLOCK because
recent hardware requires register opcodes to be executed within some
MLOCK, but the hardware also allows unlimited channels to take the
HOST1X MLOCK at the same time.
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://lore.kernel.org/r/20250708-host1x-wait-prefences-outside-mlock-v1-1-13e98044e35a@nvidia.com
Fix race condition between host1x_syncpt_alloc()
and host1x_syncpt_put() by using kref_put_mutex()
instead of kref_put() + manual mutex locking.
This ensures no thread can acquire the
syncpt_mutex after the refcount drops to zero
but before syncpt_release acquires it.
This prevents races where syncpoints could
be allocated while still being cleaned up
from a previous release.
Remove explicit mutex locking in syncpt_release
as kref_put_mutex() handles this atomically.
Signed-off-by: Mainak Sen <msen@nvidia.com>
Fixes: f5ba33fb96 ("gpu: host1x: Reserve VBLANK syncpoints at initialization")
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://lore.kernel.org/r/20250707-host1x-syncpt-race-fix-v1-1-28b0776e70bc@nvidia.com
The variable j is set, however never used in or outside the loop, thus
resulting in dead code.
Building with GCC 16 results in a build error due to
-Werror=unused-but-set-variable= enabled by default.
This patch clean up the dead code and fixes the build error.
Example build log:
drivers/gpu/drm/tegra/sor.c:1867:19: error: variable ‘j’ set but not used [-Werror=unused-but-set-variable=]
1867 | size_t i, j;
| ^
Signed-off-by: Brahmajit Das <listout@listout.xyz>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://lore.kernel.org/r/20250901212020.3757519-1-listout@listout.xyz
Before exporting a buffer, make sure it has been populated with
pages at least once.
While discussing cgroups we noticed a problem where you could export
a BO to a dma-buf without having it ever being backed or accounted for.
This meant in low memory situations or eventually with cgroups, a
lower privledged process might cause the compositor to try and allocate
a lot of memory on it's behalf and this could fail. At least make
sure the exporter has managed to allocate the RAM at least once
before exporting the object.
This only applies currently to TTM_PL_SYSTEM objects, because
GTT objects get populated on first validate, and VRAM doesn't
use TT.
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://lore.kernel.org/r/20250904021643.2050497-4-airlied@gmail.com
Before exporting a buffer, make sure it has been populated with
pages at least once.
While discussing cgroups we noticed a problem where you could export
a BO to a dma-buf without having it ever being backed or accounted for.
This meant in low memory situations or eventually with cgroups, a
lower privledged process might cause the compositor to try and allocate
a lot of memory on it's behalf and this could fail. At least make
sure the exporter has managed to allocate the RAM at least once
before exporting the object.
This only applies currently to TTM_PL_SYSTEM objects, because
GTT objects get populated on first validate, and VRAM doesn't
use TT.
Acked-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://lore.kernel.org/r/20250904021643.2050497-3-airlied@gmail.com
Before exporting a buffer, make sure it has been populated with
pages at least once.
While discussing cgroups we noticed a problem where you could export
a BO to a dma-buf without having it ever being backed or accounted for.
This meant in low memory situations or eventually with cgroups, a
lower privledged process might cause the compositor to try and allocate
a lot of memory on it's behalf and this could fail. At least make
sure the exporter has managed to allocate the RAM at least once
before exporting the object.
This only applies currently to TTM_PL_SYSTEM objects, because
GTT objects get populated on first validate, and VRAM doesn't
use TT.
Reviewed-by: Christian Koenig <christian.koenig@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://lore.kernel.org/r/20250904021643.2050497-2-airlied@gmail.com
While discussing cgroups we noticed a problem where you could export
a BO to a dma-buf without having it ever being backed or accounted for.
This meant in low memory situations or eventually with cgroups, a
lower privledged process might cause the compositor to try and allocate
a lot of memory on it's behalf and this could fail. At least make
sure the exporter has managed to allocate the RAM at least once
before exporting the object.
This only applies currently to TTM_PL_SYSTEM objects, because
GTT objects get populated on first validate, and VRAM doesn't
use TT.
Reviewed-by: Christian Koenig <christian.koenig@amd.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Simona Vetter <simona.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://lore.kernel.org/r/20250904021643.2050497-1-airlied@gmail.com
On systems with multiple GPUs there can be uncertainty which GPU is the
primary one used to drive the display at bootup. In some desktop
environments this can lead to increased power consumption because
secondary GPUs may be used for rendering and never go to a low power
state. In order to disambiguate this add a new sysfs attribute
'boot_display' that uses the output of video_is_primary_device() to
populate whether the PCI device was used for driving the display.
Suggested-by: Manivannan Sadhasivam <mani@kernel.org>
Acked-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://gitlab.freedesktop.org/xorg/lib/libpciaccess/-/issues/23
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://lore.kernel.org/r/20250811162606.587759-5-superm1@kernel.org
Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
Gma500 unnecessarily clears the framebuffer's GEM-object pointer
before calling drm_framebuffer_cleanup(). Remove this code to make
gma500 consistent with the rest of the drivers.
The change is cosmetic, as drm_framebuffer_cleanup() does not
touch the object pointer on gma500.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Link: https://lore.kernel.org/r/20250904121157.395128-1-tzimmermann@suse.de
The DRM subsystem has a set of preferred, prefixed logging functions
(drm_info, drm_warn, drm_err) which improve debuggability by including
the driver and function name in the log output.
As part of the ongoing effort to modernize logging calls,
convert a dev_err() call in the bochs hardware initialization
function to its drm_err() equivalent.
This work was suggested by the DRM TODO list.
Signed-off-by: Leander Kieweg <kieweg.leander@gmail.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://lore.kernel.org/r/20250818113530.187440-1-kieweg.leander@gmail.com
Implement support for DSI command transfer. Transmission of both Short
Packet and Long Packet is implemented, so is command transmission to
request response from peripheral device and transmission of non-read
command with BTA.
The AXI memory access mode is currently not implemented, each transfer
is performed purely using controller register interface. Short Packet
transfer can transfer up to 2 Bytes of data, Long Packet transfer can
transfer up to 16 Bytes of data.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Link: https://lore.kernel.org/r/20250831190507.327848-1-marek.vasut+renesas@mailbox.org
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
The only place in the ast driver that uses the DRAM type is the
P2A DRAM initialization for Gen2 and Gen3 of the chip. Condense
the code in ast_get_dram_info() to exactly this use case and move
it into the Gen's custom source file. Remove the field dram_type
from struct ast_device.
The AST_DRAM_ constants are also used in Gen4 POST helpers, but
independently from the dram_type field. No changes there.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://lore.kernel.org/r/20250826065032.344412-6-tzimmermann@suse.de
Lyude Paul
Geert Uytterhoeven
Lizhi Hou
Akhilesh Patil
Vamsee Vardhan Thummala
Mikko Perttunen
Mainak Sen
Brahmajit Das
Chia-I Wu
Dave Airlie
Mario Limonciello (AMD)
Jacek Lawrynowicz
Liu Ying
Dmitry Baryshkov
Thomas Zimmermann
Neil Armstrong
Zhongtian Wu
Leander Kieweg
Marek Vasut
Louis Chauvet
José Expósito
Luca Ceresoli
LiangCheng Wang
Wig Cheng
Chen Ni
Raphael Gallais-Pou
Liao Yuanhong
Min Ma
Nathan Chancellor