On Fri, 17 May 2024 19:16:21 +0100 Adrián Larumbe <adrian.larumbe@xxxxxxxxxxxxx> wrote: > Hi Boris and Thomas, > > On 02.05.2024 14:18, Thomas Zimmermann wrote: > > Hi > > > > Am 02.05.24 um 14:00 schrieb Boris Brezillon: > > > On Thu, 2 May 2024 13:59:41 +0200 > > > Boris Brezillon <boris.brezillon@xxxxxxxxxxxxx> wrote: > > > > > > > Hi Thomas, > > > > > > > > On Thu, 2 May 2024 13:51:16 +0200 > > > > Thomas Zimmermann <tzimmermann@xxxxxxx> wrote: > > > > > > > > > Hi, > > > > > > > > > > ignoring my r-b on patch 1, I'd like to rethink the current patches in > > > > > general. > > > > > > > > > > I think drm_gem_shmem_pin() should become the locked version of _pin(), > > > > > so that drm_gem_shmem_object_pin() can call it directly. The existing > > > > > _pin_unlocked() would not be needed any longer. Same for the _unpin() > > > > > functions. This change would also fix the consistency with the semantics > > > > > of the shmem _vmap() functions, which never take reservation locks. > > > > > > > > > > There are only two external callers of drm_gem_shmem_pin(): the test > > > > > case and panthor. These assume that drm_gem_shmem_pin() acquires the > > > > > reservation lock. The test case should likely call drm_gem_pin() > > > > > instead. That would acquire the reservation lock and the test would > > > > > validate that shmem's pin helper integrates well into the overall GEM > > > > > framework. The way panthor uses drm_gem_shmem_pin() looks wrong to me. > > > > > For now, it could receive a wrapper that takes the lock and that's it. > > > > I do agree that the current inconsistencies in the naming is > > > > troublesome (sometimes _unlocked, sometimes _locked, with the version > > > > without any suffix meaning either _locked or _unlocked depending on > > > > what the suffixed version does), and that's the very reason I asked > > > > Dmitry to address that in his shrinker series [1]. So, ideally I'd > > > > prefer if patches from Dmitry's series were applied instead of > > > > trying to fix that here (IIRC, we had an ack from Maxime). > > > With the link this time :-). > > > > > > [1]https://lore.kernel.org/lkml/20240105184624.508603-1-dmitry.osipenko@xxxxxxxxxxxxx/T/ > > > > Thanks. I remember these patches. Somehow I thought they would have been > > merged already. I wasn't super happy about the naming changes in patch 5, > > because the names of the GEM object callbacks do no longer correspond with > > their implementations. But anyway. > > > > If we go that direction, we should here simply push drm_gem_shmem_pin() and > > drm_gem_shmem_unpin() into panthor and update the shmem tests with > > drm_gem_pin(). Panfrost and lima would call drm_gem_shmem_pin_locked(). IMHO > > we should not promote the use of drm_gem_shmem_object_*() functions, as they > > are meant to be callbacks for struct drm_gem_object_funcs. (Auto-generating > > them would be nice.) > > I'll be doing this in the next patch series iteration, casting the pin function's > drm object parameter to an shmem object. > > Also for the sake of leaving things in a consistent state, and against Boris' advice, > I think I'll leave the drm WARN statement inside drm_gem_shmem_pin_locked. Sure, that's fine.
