drm/todo: Better defio support in the generic fbdev emulation

Commit Message

Daniel Vetter Jan. 7, 2019, 10:22 a.m. UTC

The current one essentially means you need CMA or a vmalloc backed
object, which makes fbdev emulation a special case.

Since implementing this will be quite a bit of work, capture the idea
in a TODO.

Cc: Noralf Trønnes <[e-mail]>
Signed-off-by: Daniel Vetter <[e-mail]>
---
 Documentation/gpu/todo.rst | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

Comments

Noralf Trønnes Jan. 7, 2019, 4:43 p.m. UTC | #1

Den 07.01.2019 11.22, skrev Daniel Vetter:
> The current one essentially means you need CMA or a vmalloc backed
> object, which makes fbdev emulation a special case.
> 
> Since implementing this will be quite a bit of work, capture the idea
> in a TODO.
> 
> Cc: Noralf Trønnes <[e-mail]>
> Signed-off-by: Daniel Vetter <[e-mail]>
> ---

Acked-by: Noralf Trønnes <[e-mail]>

Daniel Vetter Jan. 8, 2019, 8:03 a.m. UTC | #2

On Mon, Jan 07, 2019 at 05:43:22PM +0100, Noralf Trønnes wrote:
> Den 07.01.2019 11.22, skrev Daniel Vetter:
> > The current one essentially means you need CMA or a vmalloc backed
> > object, which makes fbdev emulation a special case.
> > 
> > Since implementing this will be quite a bit of work, capture the idea
> > in a TODO.
> > 
> > Cc: Noralf Trønnes <[e-mail]>
> > Signed-off-by: Daniel Vetter <[e-mail]>
> > ---
> 
> Acked-by: Noralf Trønnes <[e-mail]>

Thanks for taking a look, pushed to drm-misc-next.
-Daniel

Patch

diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 41da7b06195c..0a85dad876ae 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -209,6 +209,36 @@  Would be great to refactor this all into a set of small common helpers.
 
 Contact: Daniel Vetter
 
+Generic fbdev defio support
+---------------------------
+
+The defio support code in the fbdev core has some very specific requirements,
+which means drivers need to have a special framebuffer for fbdev. Which prevents
+us from using the generic fbdev emulation code everywhere. The main issue is
+that it uses some fields in struct page itself, which breaks shmem gem objects
+(and other things).
+
+Possible solution would be to write our own defio mmap code in the drm fbdev
+emulation. It would need to fully wrap the existing mmap ops, forwarding
+everything after it has done the write-protect/mkwrite trickery:
+
+- In the drm_fbdev_fb_mmap helper, if we need defio, change the
+  default page prots to write-protected with something like this::
+
+      vma->vm_page_prot = pgprot_wrprotect(vma->vm_page_prot);
+
+- Set the mkwrite and fsync callbacks with similar implementions to the core
+  fbdev defio stuff. These should all work on plain ptes, they don't actually
+  require a struct page.  uff. These should all work on plain ptes, they don't
+  actually require a struct page.
+
+- Track the dirty pages in a separate structure (bitfield with one bit per page
+  should work) to avoid clobbering struct page.
+
+Might be good to also have some igt testcases for this.
+
+Contact: Daniel Vetter, Noralf Tronnes
+
 Put a reservation_object into drm_gem_object
 --------------------------------------------