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()). > > >> + > >> /** @unplug: Device unplug related fields. */ > >> struct { > >> /** @lock: Lock used to serialize unplug operations. */ > > > > Loïc
