On Fri, Jan 22, 2021 at 2:40 PM Christian König <ckoenig.leichtzumerken@xxxxxxxxx> wrote: > > Am 22.01.21 um 14:36 schrieb Daniel Vetter: > > Requested by Thomas. I think it justifies a new level, since I tried > > to make some forward progress on this last summer, and gave up (for > > now). This is very tricky. > > > > Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxxx> > > Cc: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxxxx> > > Cc: Maxime Ripard <mripard@xxxxxxxxxx> > > Cc: Thomas Zimmermann <tzimmermann@xxxxxxx> > > Cc: David Airlie <airlied@xxxxxxxx> > > Cc: Daniel Vetter <daniel@xxxxxxxx> > > Cc: Sumit Semwal <sumit.semwal@xxxxxxxxxx> > > Cc: "Christian König" <christian.koenig@xxxxxxx> > > Cc: linux-media@xxxxxxxxxxxxxxx > > Cc: linaro-mm-sig@xxxxxxxxxxxxxxxx > > --- > > Documentation/gpu/todo.rst | 19 +++++++++++++++++++ > > 1 file changed, 19 insertions(+) > > > > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst > > index dea9082c0e5f..f872d3d33218 100644 > > --- a/Documentation/gpu/todo.rst > > +++ b/Documentation/gpu/todo.rst > > @@ -23,6 +23,9 @@ Advanced: Tricky tasks that need fairly good understanding of the DRM subsystem > > and graphics topics. Generally need the relevant hardware for development and > > testing. > > > > +Expert: Only attempt these if you've successfully completed some tricky > > +refactorings already and are an expert in the specific area > > + > > Subsystem-wide refactorings > > =========================== > > > > @@ -168,6 +171,22 @@ Contact: Daniel Vetter, respective driver maintainers > > > > Level: Advanced > > > > +Move Buffer Object Locking to dma_resv_lock() > > +--------------------------------------------- > > + > > +Many drivers have their own per-object locking scheme, usually using > > +mutex_lock(). This causes all kinds of trouble for buffer sharing, since > > +depending which driver is the exporter and importer, the locking hierarchy is > > +reversed. > > + > > +To solve this we need one standard per-object locking mechanism, which is > > +dma_resv_lock(). This lock needs to be called as the outermost lock, with all > > +other driver specific per-object locks removed. The problem is tha rolling out > > +the actual change to the locking contract is a flag day, due to struct dma_buf > > +buffer sharing. > > + > > +Level: Expert > > + > > Could you name some examples of driver locks here? I'm not aware in > anything like this in amdgpu, radeon or neveau. ttm based drivers are all fine. It's everything else which is a problem, and it gets worse if you mix helpers (like shmem helpers, which have their own locks internally) with render drivers (again with their own mutexes). > And yes sounds like a job for the appropriate driver maintainer. The problem is, this one you can't do driver-by-driver because of the dma-buf contract. I mean we tried for p2p at first, it's just too much. I tried to do it last summer just for shmem gem helpers, and you really have to tackle all the drivers in one go (even if you ignore dma-buf for now, where we side-stepped the problem with pinning). This is "scares danvet" levels of nasty. -Daniel > Thanks, > Christian. > > > Convert logging to drm_* functions with drm_device paramater > > ------------------------------------------------------------ > > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
