On 30/09/2025 18:52, Boris Brezillon wrote:
On Tue, 30 Sep 2025 18:31:11 +0200
Loïc Molinari <[email protected]> wrote:
On 30/09/2025 12:34, Boris Brezillon wrote:
On Mon, 29 Sep 2025 22:03:14 +0200
Loïc Molinari <[email protected]> wrote:
diff --git a/drivers/gpu/drm/panthor/panthor_device.h
b/drivers/gpu/drm/panthor/panthor_device.h
index 4fc7cf2aeed5..54ca61567426 100644
--- a/drivers/gpu/drm/panthor/panthor_device.h
+++ b/drivers/gpu/drm/panthor/panthor_device.h
@@ -135,6 +135,9 @@ struct panthor_device {
/** @devfreq: Device frequency scaling management data. */
struct panthor_devfreq *devfreq;
+ /** @huge_mnt: tmpfs mount point with Transparent Hugepage enabled. */
+ struct vfsmount *huge_mnt;
Now that we have a helper to create a huge mountpoint, wouldn't it
make sense to have this field in drm_device instead of having each
driver add a huge_mnt field to their <driver>_device object.
Not sure this should be enforced for all DRM drivers since most of them
don't create separate huge mountpoints (only 4 for now including this
patchset) and I guess some maintainers might prefer to depend on the
sysfs interace to enable huge pages.
I'm not saying we should create the huge mountpoint by default, but if
this is a generic helper, it makes sense to also manage this mountpoint
internally. In the end, it'd be a small price to pay for drivers that
don't need it (the size of a pointer in the drm_device object), and
with this in place, driver wouldn't even have to call
drm_gem_shmem_huge_mnt_free() manually (can be automated with a
drmm_add_action_or_reset() calling kern_unmount() inside
drm_gem_shmem_huge_mnt_create()).
Ok. I've just sent a v3 of the series with the huge vfsmount stored in
the drm_device struct. This also allowed to get rid of some of the
*_with_mnt helpers.
+
/** @unplug: Device unplug related fields. */
struct {
/** @lock: Lock used to serialize unplug operations. */
Loïc
Loïc
