diff options
author | Jaya Kumar <jayakumar.lkml@gmail.com> | 2007-05-08 03:37:37 -0400 |
---|---|---|
committer | Linus Torvalds <torvalds@woody.linux-foundation.org> | 2007-05-08 14:15:26 -0400 |
commit | 60b59beafba875aef6d378078bce0baf2287ae14 (patch) | |
tree | bb599c0e2ad43ee8f515a9f9af009442931b6a37 /Documentation/fb | |
parent | 3a2842480bbef42c3c90e14c1f378360d8c20a0c (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')
-rw-r--r-- | Documentation/fb/deferred_io.txt | 75 |
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 @@ | |||
1 | Deferred IO | ||
2 | ----------- | ||
3 | |||
4 | Deferred IO is a way to delay and repurpose IO. It uses host memory as a | ||
5 | buffer and the MMU pagefault as a pretrigger for when to perform the device | ||
6 | IO. The following example may be a useful explaination of how one such setup | ||
7 | works: | ||
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 | |||
24 | As can be seen from above, one benefit is roughly to allow bursty framebuffer | ||
25 | writes to occur at minimum cost. Then after some time when hopefully things | ||
26 | have gone quiet, we go and really update the framebuffer which would be | ||
27 | a relatively more expensive operation. | ||
28 | |||
29 | For some types of nonvolatile high latency displays, the desired image is | ||
30 | the final image rather than the intermediate stages which is why it's okay | ||
31 | to not update for each write that is occuring. | ||
32 | |||
33 | It may be the case that this is useful in other scenarios as well. Paul Mundt | ||
34 | has mentioned a case where it is beneficial to use the page count to decide | ||
35 | whether to coalesce and issue SG DMA or to do memory bursts. | ||
36 | |||
37 | Another one may be if one has a device framebuffer that is in an usual format, | ||
38 | say diagonally shifting RGB, this may then be a mechanism for you to allow | ||
39 | apps to pretend to have a normal framebuffer but reswizzle for the device | ||
40 | framebuffer at vsync time based on the touched pagelist. | ||
41 | |||
42 | How to use it: (for applications) | ||
43 | --------------------------------- | ||
44 | No changes needed. mmap the framebuffer like normal and just use it. | ||
45 | |||
46 | How to use it: (for fbdev drivers) | ||
47 | ---------------------------------- | ||
48 | The following example may be helpful. | ||
49 | |||
50 | 1. Setup your structure. Eg: | ||
51 | |||
52 | static struct fb_deferred_io hecubafb_defio = { | ||
53 | .delay = HZ, | ||
54 | .deferred_io = hecubafb_dpy_deferred_io, | ||
55 | }; | ||
56 | |||
57 | The delay is the minimum delay between when the page_mkwrite trigger occurs | ||
58 | and when the deferred_io callback is called. The deferred_io callback is | ||
59 | explained below. | ||
60 | |||
61 | 2. Setup your deferred IO callback. Eg: | ||
62 | static void hecubafb_dpy_deferred_io(struct fb_info *info, | ||
63 | struct list_head *pagelist) | ||
64 | |||
65 | The deferred_io callback is where you would perform all your IO to the display | ||
66 | device. You receive the pagelist which is the list of pages that were written | ||
67 | to during the delay. You must not modify this list. This callback is called | ||
68 | from a workqueue. | ||
69 | |||
70 | 3. Call init | ||
71 | info->fbdefio = &hecubafb_defio; | ||
72 | fb_deferred_io_init(info); | ||
73 | |||
74 | 4. Call cleanup | ||
75 | fb_deferred_io_cleanup(info); | ||