Commit | Line | Data |
---|---|---|
60b59bea JK |
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 | |
01dd2fbf | 6 | IO. The following example may be a useful explanation of how one such setup |
60b59bea JK |
7 | works: |
8 | ||
9 | - userspace app like Xfbdev mmaps framebuffer | |
529e55b6 | 10 | - deferred IO and driver sets up fault and page_mkwrite handlers |
60b59bea | 11 | - userspace app tries to write to mmaped vaddress |
529e55b6 NP |
12 | - we get pagefault and reach fault handler |
13 | - fault handler finds and returns physical page | |
60b59bea JK |
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 | |
01dd2fbf | 31 | to not update for each write that is occurring. |
60b59bea JK |
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); |