[2/2] drm/todo: Clarify situation around fbdev and defio

Submitted by Thomas Zimmermann on Oct. 25, 2019, 9:27 a.m.

Details

Message ID 20191025092759.13069-3-tzimmermann@suse.de
State Accepted
Commit 955a72cea507051e366a4b70de86d974565bfe93
Headers show
Series "drm/fb-helper: Documentation update for defio" ( rev: 1 ) in DRI devel

Not browsing as part of any series.

Commit Message

Thomas Zimmermann Oct. 25, 2019, 9:27 a.m.
The TODO item is misleading and makes it seem that fbdev emulation
cannot be used with SHMEM. Rephrase the text to describe the current
situation more correctly.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
---
 Documentation/gpu/todo.rst | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

Patch hide | download patch | download mbox

diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 73c51b5a0997..6792fa9b6b6b 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -206,10 +206,10 @@  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).
+which means drivers need to have a special framebuffer for fbdev. The main
+issue is that it uses some fields in struct page itself, which breaks shmem
+gem objects (and other things). To support defio, affected drivers require
+the use of a shadow buffer, which may add CPU and memory overhead.
 
 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

Comments

Den 25.10.2019 11.27, skrev Thomas Zimmermann:
> The TODO item is misleading and makes it seem that fbdev emulation
> cannot be used with SHMEM. Rephrase the text to describe the current
> situation more correctly.
> 
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
>  Documentation/gpu/todo.rst | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index 73c51b5a0997..6792fa9b6b6b 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -206,10 +206,10 @@ 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).
> +which means drivers need to have a special framebuffer for fbdev. The main
> +issue is that it uses some fields in struct page itself, which breaks shmem
> +gem objects (and other things). To support defio, affected drivers require
> +the use of a shadow buffer, which may add CPU and memory overhead.
>  

Ah yes, there's a todo on this. Look good to me:

Acked-by: Noralf Trønnes <noralf@tronnes.org>

>  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
>