On Tue, Sep 29, 2020 at 05:14:37PM +0200, Thomas Zimmermann wrote: > Instances of struct dma_buf_map should be useful throughout DRM's > memory management code. Furthermore, several drivers can now use > generic fbdev emulation. > > Signed-off-by: Thomas Zimmermann <tzimmermann@xxxxxxx> Acked-by: Daniel Vetter <daniel.vetter@xxxxxxxx> > --- > Documentation/gpu/todo.rst | 24 ++++++++++++++++++++++-- > 1 file changed, 22 insertions(+), 2 deletions(-) > > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst > index 3751ac976c3e..023626c1837b 100644 > --- a/Documentation/gpu/todo.rst > +++ b/Documentation/gpu/todo.rst > @@ -197,8 +197,10 @@ Convert drivers to use drm_fbdev_generic_setup() > ------------------------------------------------ > > Most drivers can use drm_fbdev_generic_setup(). Driver have to implement > -atomic modesetting and GEM vmap support. Current generic fbdev emulation > -expects the framebuffer in system memory (or system-like memory). > +atomic modesetting and GEM vmap support. Historically, generic fbdev emulation > +expected the framebuffer in system memory or system-like memory. By employing > +struct dma_buf_map, drivers with frambuffers in I/O memory can be supported > +as well. > > Contact: Maintainer of the driver you plan to convert > > @@ -446,6 +448,24 @@ Contact: Ville Syrjälä, Daniel Vetter > > Level: Intermediate > > +Use struct dma_buf_map throughout codebase > +------------------------------------------ > + > +Pointers to shared device memory are stored in struct dma_buf_map. Each > +instance knows whether it refers to system or I/O memory. Most of the DRM-wide > +interface have been converted to use struct dma_buf_map, but implementations > +often still use raw pointers. > + > +The task is to use struct dma_buf_map where it makes sense. > + > +* Memory managers should use struct dma_buf_map for dma-buf-imported buffers. > +* TTM might benefit from using struct dma_buf_map internally. > +* Framebuffer copying and blitting helpers should operate on struct dma_buf_map. > + > +Contact: Thomas Zimmermann <tzimmermann@xxxxxxx>, Christian König, Daniel Vetter > + > +Level: Intermediate > + > > Core refactorings > ================= > -- > 2.28.0 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
