aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/fb/deferred_io.txt
diff options
context:
space:
mode:
authorJaya Kumar <jayakumar.lkml@gmail.com>2007-05-08 03:37:37 -0400
committerLinus Torvalds <torvalds@woody.linux-foundation.org>2007-05-08 14:15:26 -0400
commit60b59beafba875aef6d378078bce0baf2287ae14 (patch)
treebb599c0e2ad43ee8f515a9f9af009442931b6a37 /Documentation/fb/deferred_io.txt
parent3a2842480bbef42c3c90e14c1f378360d8c20a0c (diff)
fbdev: mm: Deferred IO support
This implements deferred IO support in fbdev. Deferred IO is a way to delay and repurpose IO. This implementation is done using mm's page_mkwrite and page_mkclean hooks in order to detect, delay and then rewrite IO. This functionality is used by hecubafb. [adaplas] This is useful for graphics hardware with no directly addressable/mappable framebuffer. Implementing this will allow the "framebuffer" to be accesible from user space via mmap(). Signed-off-by: Jaya Kumar <jayakumar.lkml@gmail.com> Signed-off-by: Antonino Daplas <adaplas@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'Documentation/fb/deferred_io.txt')
-rw-r--r--Documentation/fb/deferred_io.txt75
1 files changed, 75 insertions, 0 deletions
diff --git a/Documentation/fb/deferred_io.txt b/Documentation/fb/deferred_io.txt
new file mode 100644
index 000000000000..73cf9fb7cf60
--- /dev/null
+++ b/Documentation/fb/deferred_io.txt
@@ -0,0 +1,75 @@
1Deferred IO
2-----------
3
4Deferred IO is a way to delay and repurpose IO. It uses host memory as a
5buffer and the MMU pagefault as a pretrigger for when to perform the device
6IO. The following example may be a useful explaination of how one such setup
7works:
8
9- userspace app like Xfbdev mmaps framebuffer
10- deferred IO and driver sets up nopage and page_mkwrite handlers
11- userspace app tries to write to mmaped vaddress
12- we get pagefault and reach nopage handler
13- nopage handler finds and returns physical page
14- we get page_mkwrite where we add this page to a list
15- schedule a workqueue task to be run after a delay
16- app continues writing to that page with no additional cost. this is
17 the key benefit.
18- the workqueue task comes in and mkcleans the pages on the list, then
19 completes the work associated with updating the framebuffer. this is
20 the real work talking to the device.
21- app tries to write to the address (that has now been mkcleaned)
22- get pagefault and the above sequence occurs again
23
24As can be seen from above, one benefit is roughly to allow bursty framebuffer
25writes to occur at minimum cost. Then after some time when hopefully things
26have gone quiet, we go and really update the framebuffer which would be
27a relatively more expensive operation.
28
29For some types of nonvolatile high latency displays, the desired image is
30the final image rather than the intermediate stages which is why it's okay
31to not update for each write that is occuring.
32
33It may be the case that this is useful in other scenarios as well. Paul Mundt
34has mentioned a case where it is beneficial to use the page count to decide
35whether to coalesce and issue SG DMA or to do memory bursts.
36
37Another one may be if one has a device framebuffer that is in an usual format,
38say diagonally shifting RGB, this may then be a mechanism for you to allow
39apps to pretend to have a normal framebuffer but reswizzle for the device
40framebuffer at vsync time based on the touched pagelist.
41
42How to use it: (for applications)
43---------------------------------
44No changes needed. mmap the framebuffer like normal and just use it.
45
46How to use it: (for fbdev drivers)
47----------------------------------
48The following example may be helpful.
49
501. Setup your structure. Eg:
51
52static struct fb_deferred_io hecubafb_defio = {
53 .delay = HZ,
54 .deferred_io = hecubafb_dpy_deferred_io,
55};
56
57The delay is the minimum delay between when the page_mkwrite trigger occurs
58and when the deferred_io callback is called. The deferred_io callback is
59explained below.
60
612. Setup your deferred IO callback. Eg:
62static void hecubafb_dpy_deferred_io(struct fb_info *info,
63 struct list_head *pagelist)
64
65The deferred_io callback is where you would perform all your IO to the display
66device. You receive the pagelist which is the list of pages that were written
67to during the delay. You must not modify this list. This callback is called
68from a workqueue.
69
703. Call init
71 info->fbdefio = &hecubafb_defio;
72 fb_deferred_io_init(info);
73
744. Call cleanup
75 fb_deferred_io_cleanup(info);